How-To for creating a debug build

[StuAtGit]

It would be nice to be able to create a non-minified, non-all-in one file build. They are very useful for:

• debugging
• deployment in environments where I just that extra few percent reduction in bandwidth I get from gzip + minified over just plain old nginx gzip = 9 compression isn't worth losing the ability to debug side-by-side with a user.
• compatibility with external configuration systems (e.g a salt template for a javascript file that sets up various routes/hosts that may vary from environment to environmet). Yes, I did end up with a conf.js in the public folder, but storing stuff in window.[config_variable] did feel a little icky.

Maybe there's some simple way to deploy a non-minified build that's obvious to experts.

But for someone, like me, that has used some node, grunt, bower, etc, for a few months, but is still relatively unfamiliar with the scope of the javascript package ecosystem, I can't seem to find a simple way. So maybe a How-To would help? If you could sketch it out enough for me to figure it out, I can massage it into something suitable for the wiki...

But... I can't even figure out how to assemble the files I have by hand into a directory structure without getting "Unexpected Token Import" or just a blank page issues, that leave me a little stumped as to what I should do next.

[viankakrisna]

See this issue
#1354

[StuAtGit]

Hmm... the issue @viankakrisna linked to is interesting, but not sure how it addresses this specific issue - I'm not trying to customize the build folder for my particular project, I just don't want my source to be minified and inlined into one file. It's fine if there is a standard option with a standard layout that does this.

[StuAtGit]

To be clear, I'm looking for a standard option to generate debug builds.

[Timer]

You should just be able to ship the source map with the production build and get the niceties of debugging, actual source, etc.

[StuAtGit]

@Timer Thanks! Was shipping, and did not know... but also ... only sort of kind of it does that. The debugger can see the actual source, so that's mostly there (and I just learned that)... but still, it nice to have the actual source file - and server-side, and not just in a debugger - especially when dealing with configs that vary - the public options gets you there, but a little roundabout.

Also, for a fairly simple app, sometimes it just nice to have a clearer idea what is going on with your source, from when nginx loads it on - actually see the calls to load things, etc.

If it helps, this is from the perspective of a mostly-backend dev who creates a ui on occasion and is more easily confused by all the magic then a skilled front-end dev.

[Timer]

Is this what you're looking for to manage configuration?
https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/template/README.md#adding-custom-environment-variables

As for what you're trying to do (non-minified, etc), we don't provide any way to do that -- though you could use require.ensure to split your build into multiple files. I'm not sure if support will be added for such a thing without excellent reasoning.

[StuAtGit]

Ah ok. Thanks for the info @Timer require-ensure is cool, but not really what I'm looking for. Sounds like it's best to close this as won't-fix for now. Will do that.

I come from a world where I don't minify and inline without excellent reasoning (I've never seen a convincing bandwidth argument (vs gzip), even for mobile, but javascript & decompress cpu overhead, I don't know as much about that), so I think it's just a different POV.

[StuAtGit]

I can't add won't fix, for some reason, so that will need to be added by someone else.

[linzhaoken]

A debug build will be good, if we want to do App Security Scan such as IBM AppScan Source tool, which support pure javascript app scan.