I love using npm script as my build tool. By doing so, we could make sure the scripts are not sooooo complicated and easy to read (comparing to gul...
For further actions, you may consider blocking this person and/or reporting abuse
I see the reasoning behind your approach, but – at least for a production-ready project – it feels a bit hack-y to me!
An alternative organizational method might be to move your NPM script definitions in to their own dedicated shell files within a
build/directory. This way, you can organize your script files without having to pepper yourpackage.jsonwith unnecessary entries. Though it won't give you the prettynpm runsection headers you demonstrated (obviously), the directory structure gives you a similar kind of at-a-glance legibility. And using dedicate shell scripts will definitely simplify long-term package maintenance...Anyway, just my two-cents; thanks for thinking!
I definitely agree with you. A
build/directory is definitely better for production projects.But, I think this is a hack that wouldn't really hurt to add. It is not at all contradictory to having
build/. And the good thing about it is the prettynpm runthat will give a nicer guidelines to, maybe new developers who wants to find out the building instructions available.true enough. especially re: those “new developers who want to find... instructions”, a file system abstraction is probably suboptimal!
This is a cool trick :)
Makes me wish Node/NPM had used a file format that supports comments, though - Rust uses TOML, and it's hard to go back to JSON for config files after using that :(
Yes! Although it isn't really a solution, it does the trick if we want a neater
npm runoutput.I am happy you find this trick useful.