06000208
commented
4 years ago One major issue I've noticed ahead of time with using npm modules is that, when you do wish to modify code (such as making changes to a command) the approach would run counter to being able to do that easily, as the code you want to change wouldn't be in your repository but rather under /node_modules/, and making changes to installed npm modules is not a solution.
While you could of course drop the module into your project and load it that way rather than from an npm module, some of the main advantages the approach offers may be lost from doing so.
There's also the matter that a reasonable scope and clarity of purpose when it comes to sandplate needs to be maintained:
- I don't have the time or energy to build a modular ecosystem ontop of npm, it's simply too lofty & hefty a goal to consider for now (aside from my upcoming testing)
- Sandplate isn't an npm package, and wasn't ever designed to be one. What's currently being offered within it doesn't translate well either, as far as I'm aware
Just some food for thought while I'm working on 0.0.7
I want sandplate to have an extensible and modular approach that allows for new abstract functionality and modules in the form of plugins or packages.
For right now, the handler framework does enough, but a more powerful solution will be needed in the future, because as it stands, the implementation of most advanced features requires you to make least some changes to sandplate itself in order to facilitate whatever it may be you want to do. This is especially relevant when it comes to functionality that arguably shouldn't be done as part of sandplate itself, but that I still wish to offer and maintain seperately, such as:
The "easiest" way to implement these things separately from sandplate would be to fork the project, but this creates a very undesirable situation for future updates and when attempting to use multiple features done this way at the same time, such as both the web interface and localization support, or any such combination.
We should never have to resort to needless manual work to update our projects or merge forks together to suit our needs, as this harms the maintainability of sandplate and any projects stemming from it.
Relevant concepts include abstraction layers or inversion of control, the latter appearing fairly promising, but either approach may make sandplate significantly more complex than desired.
If we do manage to improve the handler framework to the extent needed, we run into significant problems when it comes to distribution and the addition of dependencies. Hence, the improved handler should be built around using NPM for the almost seamless installation of additional features and modules ontop of sandplate, with that being the default and intended method, as this seems like the best way to go.
If this is successful, most functionality currently included as part of sandplate could be moved out to seperate (and optional) npm packages, further increasing sandplate's modularity.
There is a number of software out there (although not necessarily related to javascript or node.js at all) that are built with extreme modularity and mitigate all the relevant issues in their own ways, and they can serve as examples of what I wish to do, in a way:
As of writing, this comes down to how well this can be done in node.js and the NPM package manager without needing our own repository service or forking npm (core parts of atom's approach), and would definitely require a huge amount of planning and testing.
I'm going to try my hand at making various proof of concepts, and will eventually post updates on this issue with the results of my experimentation.