Turn off source maps by default

[daveredfern]

It seems to be on by default when running npm run watch. Isn't this meant to be on when we run the dev version? npm run watch-dev or something?

[jakecobley]

Currently two options are:

• Default (dev) with all tools, exception minification and compression enabled.
• Production which has the tools disabled with the exception of minification.

I haven't come across a time when I wouldn't want or need sourcemaps etc. disabled. If there's a need to disable sourcemaps etc. how about a --disabletools flag or something similar?

[daveredfern]

@jakecobley I haven't come across a time I want it ;).

I'm sure this is a recent addition?

I like to see the rough output of the CSS. Lean and mean like. I also like inspecting the full output of the CSS rather than the source – although not really noticed it much.

Don't mind keeping it if the majority like it.

@gazjoy thoughts?

[gazjoy]

@jakecobley @daveredfern Personally I don't use source maps. I know where the sass lives and when debugging I want to debug the css output not the sass.

I can live without it.

[daveredfern]

@gazjoy @jakecobley I'm sure before we had the option to run watch as dev? npm run watch and npm run watch-dev or something?

What other tools are running that would come under the --disabletools umbrella @jakecobley ?

[jakecobley]

@daveredfern We had the option a couple of versions back but it was flushed out when the Gulp process was cleaned up.

The main reason npm run watch-dev was binned was a combination of I never used it without sourcemaps, and someone, I can't remember who, was using ChopChop and had no ideal about sourcemaps at all. This sparked the question why isn't this just enabled by default.

Sourcemaps would be the only one I would currently put under the --disabletools flag. But I'd rather label its tools and not sourcemaps for future proofing. i.e. JS sourcemaps, bundling etc. We could put combine-mq under it if that's also something you would like to be able to disable?

[gazjoy]

@jakecobley

If you are precious about this, how about we maintain a chop chop fork of your gulp file? That way we can pick and choose the bits that are relevant to chop chop? You could maintain your main branch of development and let us know when you have added something new and we could choose whether to cherry-pick it in?

Source maps aren't a requirement and I don't see the point of what it helps with? The outputted CSS it what we should be debugging, that is what is rendered by the browser and the thing that can affect the performance metrics.

Im guessing the only reason to use source maps is because you don't know where a chunk of sass belongs? We have designed a modular, pattern based system so that you should know exactly where the Sass should belong. We are working on better documentation for this but are just held up at the minute by the #131 issue.

[daveredfern]

I think the use case is for someone who is not familiar with the structure of chopchop to help them find where things live.

I'm not sure that is a reason alone to keep sourcemaps. It feels like it would only prolong and encourage people to be lazy and not learn the basic architecture of the front end. Generally class names equal file names:

• Anything without a class belongs in base.
• Anything prepended with g- or u- live in utilities.
• All other classes belong in components.

This might be less of an issue over time as documentation improves and therefore the education and knowledge is spread.

As a happy medium, maybe it could remain until the docs are improved?

[jakecobley]

As discussed this afternoon, sourcemaps have been removed in PR #152.