4 ms·
Sure, as long as you can express your entire pipeline as a single shell statement and don't care about Windows.
by lexicality 9y ago
Sure, as long as you can express your entire pipeline as a single shell statement and don't care about Windows.
- bmarkovic 9y agoDoes anyone? Doing web dev on Windows means exposing yourself to a world of pain, which is why most are on MacOs or Linux anyway.
- lexicality 9y agoSure. I do, and I'm sure most people in big corps do too. All modern high level languages have very good cross-platform system libraries and build tools for those languages usually use that language to run. Occasionally you'll run into someone that's still using Makefiles and have to break out msys but other than that it's generally fine.
- moron4hire 9y agoA world of pain? I've had much more painful experiences trying to get Ruby on Rails setup on a new MacBook.
- nobleach 9y agoYou've found Ruby easier to manage on Windows? Can you serve it from Windows? (other than Webrick) I'm not trying to be inflammatory at all. I just never had any luck with any Ruby/Rails type stuff when I was forced to use Windows. I ended up resorting to JRuby.
- lucideer 9y agoThere's really no need for one-liners - npm can run shell script files just fine. What complex things are you doing that Windows compat creates problems? (presuming you've got some form of bash on Windows) I tend to tuck any complexity into JS devDependency libraries when using npm scripts which takes care of most cross-platform issues.
- fenomas 9y agoIf you're using npm to run shell or node scripts, then you're running your tasks with shell or node scripts. Just because you typed "npm test" instead of "./test.sh" doesn't mean npm is doing anything to help manage your tasks.
- Androider 9y agoScripts + NPM are better together, for example because scripts executed under NPM have the local packages binaries in the path. This makes it very easy to have a fully locally installed build environment with no system dependencies. And if you do use webpack, it also helps in providing a uniform interface (Is "test" a Webpack target or a script? Who cares, just use "npm test", it'll work either way, also if we change it in the future). And it's not an either-or case in the real world. Our company has a big Webpack config that does a lot, and still we have 15+ scripts as well (static analysis, inserting copyright headers, sourcemap uploads, 3rd party vendoring, release scripts...). Some things are better in WP (building), while some things are just simpler with a shell script.
- lucideer 9y agonpm (more specifically package.json) is helpful in this context for a variety of reasons: - it's a single, central document listing your important pipelines and their purposes - anyone unfamiliar with your setup can look at the scripts property and get a very good idea very quickly - it's auto-detected and even auto-parsed by some tools (a Ctrl-Shift-B in vscode, for example, will allow me to select a build pipeline - there's no more well-supported central format for arbitrary loose shell scripts) - it's a consistent entry point. If you edit your npm script to point to a separate shell script, or to run webpack/whatever instead - anything external (IDEs, CI configs) pointing to npm need not change The above are not unique to npm, but it's a well-supported, well-understood, and very simple setup that does the above.
- lexicality 9y agoIf you're going to go to all the trouble of writing (and debugging) bash scripts, why would you not just use Grunt to do the majority of it for you? EDIT: (Asking this in the context of the grandparent comment suggesting getting rid of build systems in favour of NPM scripts)
- jeswin 9y ago> Sure, as long as you can express your entire pipeline as a single shell statement Single line shell pipelines :) Exactly why I made this - https://github.com/jeswin/basho/ https://github.com/jeswin/basho/