[Fuzzwah]

I'm a content guy who knows enough web dev to be dangerous.

I made 3 manual edits to a css file to fix a couple of incorrect background colours in our web content the other day. I was a good boy and made a pull request for those same changes in the git repo.

Our developer explained that he doesn't actually edit the css file. He would have to work out the change in the hue (as a percent of the base colour) and update that in the sass file, then use gulp to compile a fresh version of the output css.

He said that this was a simple build process to get set up on my machine so I could do it myself in the future.

He uses a mac. I use windows.

4 hours later after hitting so many hurdles I finally got it working. I can't even recall all the issues, but do recall that I side stepped them all by moving to a particular version of npm which actually used a sane system for storing the dependencies.

With out that version of npm this simple build process required 15,000 files in my node_modules subdirectory in a structure so deep and convoluted Windows couldn't create them....

Of course now that I'm armed with the toolset to make these changes I've reverted to testing changes in chrome dev tools and emailing him requests.

[bhrgunatha]

> this simple build process required 15,000 files in my node_modules subdirectory

You would think people learned a lesson about packaging every tiny item as a dependency with left pad, but apparently yesterday it was downloaded 16104 times.

[1] https://www.npmjs.com/package/left-pad

[Ajedi32]

> He uses a mac. I use windows.

Aaah, good luck. For me it's basically gotten to the point where if the build doesn't immediately work on Windows, I just fire up a Linux VM and work off of that.

And that's not just for front-end projects, but for open-source projects in general. Windows support is often really lacking in an environment where devs seem to use Linux and Mac almost exclusively.

[Fuzzwah]

That was actually my first response too... I set up the build process on my linux test server while I continued to battle to get it working on my daily drive win10 machine.

[akhilcacharya]

At least now we have WSL to work with.

[thecotne]

actually it's bad when build artifacts are included in git repository

so when you clone repo or edit it directly in github you don't have option to edit wrong file (compiled css file for example)

but i agree that js community has everything very complicated for learning but it's not that bad for everyone that already knows how tings work here

[LaxisB]

a big problem with npm is, that a lot of package authors don't use the .npmignore [0] which leads to EVERYONE downloading your source/, test/ and docs/ folder even if only that one file in build/ is needed. That, combined with the micromodule mindset, leads to insanity

[0]: https://docs.npmjs.com/misc/developers#keeping-files-out-of-...

[pdimitar]

That's a very bad way of handling it. When will people learn that you can't rely on everyone being a good citizen? Is it really so hard to realize that you need to make your technology sane from the very beginning?

[pdonorio]

Fear not. We have a tool for that in bower https://github.com/blittle/bower-installer, so I guess there will be one very similar in npm too. :)

[jrochkind1]

Sass is awesome, and one of the few pieces of the 'compilation toolchain hell' I _don't_ hate.

But you ideally shouldn't have your CSS build product in the repo if you're using SASS. That would avoid the confusion of editing the wrong file (the compiled output artifact, which ought not to be in the repo).

[sopooneo]

I read this as the CSS was live edited on a production server.

[extra88]

If there are other things to build for production, sure, throw SASS in too but if not, it's not worth it just to keep your repo "pure."

[mikeschmatz]

> He uses a mac. I use windows.

That's when I knew things were about to get interesting :-)