Issue with CLI-bundler when overriding bootstrap styles (using SASS)

Another suggestion for maintaining such a big code base. It might be simpler to package your plugins (every feature folder) into individual npm package, same thing with your js-library.

Your company can use private npm registry on GitHub, or boot up a private https://verdaccio.org/ server (which will proxy public npm registry too, it would speed up npm install too because of cache). Or even simpler, just use git repo as npm package, but you have to be careful about the dist files (read Consume Plugin in https://aurelia.io/docs/plugins/write-new-plugin).

Once your private dependencies are from npm packages, your app setup will be much simpler, and build will be faster because dependencies were prebuilt (by babel or tsc).

Best of all, this step can be done before you move away from webpack. You can take your time to move dependencies to npm packages one by one, verify them one at a time. This will reduce the complexity of your app setup regardless of the choice of bundler.

2 Likes

Hi @huochunpeng

Thank you for the suggestions. I fully agree with you.

My current project will become a lot bigger. Its internal codename is Kermit and it’s a migration of an existing .NET WinForms application for internal project communication management. It will include managing entire product development projects including meetings, agendas, to do lists, etc. and it will offer related document and e-mail/message management, possibly with linking to Outlook mailboxes (using an Outlook plugin to realize integration). And that’s just the current functionality of the WinForms app. The web based Aurelia app (backed by a .NET 5 API) will contain a quite sophisticated (end-user configurable) authorization mechanism, related user and user role management, and several new features. I estimate that currently only about 5-10% of its functionality is implemented in the new Aurelia project. So the number of views and HTML behaviors will grow substantially in the next months.

So I indeed intend migrate those features to plugins. However, I cannot upload any packages to an online NPM repository like GitHub, because my company’s policy does not allow that. The entire code base has to be kept on-premises. My colleague and I have an on-premise GitLab environment that is used for software development issue tracking, the git repositories, and CI/CD. I will certainly investigate possibilities for hosting a private in-company NPM package server, but for now I will prefer to put the plugins in the same git repository as Kermit itself, thus creating a monorepo.

I intended to use the same bundler for all my Aurelia projects and plugins, so it seemed more logical to switch to another bundler first. However, you are right that migrating the features to plugins first might actually be easier instead. I will give it a try.

In a previous post, you mentioned that you also maintain an unofficial Aurelia 1 dumber skeleton ( npx makes dumberjs ). Can it be used for plugin skeletons as well (for the standalone dev-app functionality of the plugins)?

1 Like

Yes, same as cli bundler skeleton, that dumber aurelia 1 skeleton also provided both app and plugin (with dev-app too) project skeletons.

2 Likes