-
Notifications
You must be signed in to change notification settings - Fork 868
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use InstallDirectory to locate node tasks instead of the WorkingDirectory #434
Conversation
WorkingDirectory
ping |
Hey, sorry for the late response. I don't fully understand the implications of this change. Can you give an example of how the behavior would differ before/after this patch? Could this be a breaking change for some users? |
No problem. I do not think this should have a big impact in general. People actually using installDir and workDir might need to reconfigure the path, but I think it makes more sense that in this case the installDir is used (as for NPM itself) and not the workingDir. If desired I can also put a boolean switch to trigger the use of I try to show my actual config which runs pretty well (I think) and should show the benefit of a consolidated node_modules location for one complete project: Structure
POM Toplevel
POM Module 1
karma.conf.js
|
👍 would like to see some form of this get released asap. |
I'm sorry I've been so slow at reviewing this! The issue is about optimisation, right? About not having to litter the project directory with node_moduels everywhere? I had a proper look, and I have some concerns. First of all, this change will be a breaking change, so it would need a 2.0 release of the plugin, and break people's setup in unexpected ways. But I don't like the thought of adding a boolean flag either - it's one more configuration flag to keep track of, and there are already too many. Arguably this could be seen as a problem with the npm ecosystem itself rather than with this maven plugin - in Java we have .m2 which caches the dependencies, and they are share between modules, so that you don't have the extra overhead of having jar files spread around everywhere. While npm installs things locally everywhere. Have you tried using ied for this purpose? It's a drop-in replacement for npm, inspired by ~/.m2 layout and the nix package manager. It symlinks packages instead of copying them everywhere, which should solve the problem you're trying to solve. |
In the end its all about locating the initial command files, like the grunt script itself. Once within grunt the resolution seems fine as all node/npm tasks are found correctly. I see several possibilities to achieve that:
For me the most logical is using the installdir, as thats what installdir means. But i understand that this might break existing projects. ( all tests are stable atm) What do you think? |
Ok, I see, it's all about the location of Gruntfile etc? And you want the gruntfiles to be shared amongst all modules? |
You can also do something like "npm run-script grunt", then in package.json in the submodule you have an npm script which calls "node ../../node_modules/grunt/bin/grunt xxx". And then use the npm mojo. |
Erm no. The problem is the "hardcoded" location of the grunt task bash script in the class |
I see what you mean. Make GruntRunner at all was a mistake, and it really should be removed. (We only need to keep the install mojo and the npm mojo) The best way to run builds in node/npm in general is to simple use npm scripts (and the npm mojo with this plugin). That means you have full flexibility to do whatever you want, including giving an explicit location for every task to run. It's really a lot like using exec-maven-plugin, except you have "node" and "npm" on your path. I would consider GruntRunner more like a handy preset that works in most cases, than a catch-all go-to for every case, in which something more low-level like the npm mojo is needed. |
Hey there. I have given it another try, but I would really like to avoid using yet-another-frontend-plugin. I have now added a little We are currently using a own hosted plugin version from my fork and I would love to get rid of that so that I can follow your updates easier. Could you take another quick look? All the tests are running well from what I see. If you still don't like to add the Pull Request please reject this one so that i can bury my hopes :) |
That looks a lot better! Then it's also backwards compatible. Thanks! |
Hey Eirslett Thanks! |
This is to support Multi-Module structure where the parent is "just" installing NPM / Node and the child modules are actually calling the build tasks like Grunt / Karma