I think I'm okay with doing this, as long as there are no good reasons why this shouldn't be done.

So far, I can't think of why adding this would be bad... But still thinking. Once we add this, it'll be much harder to remove it.

Is there anything similar in the standard Go toolchain? I know it automatically sets build tags for the current Go version, as well as architecture and OS. But is there anything else that it does that would be more akin to the minify flag/build tag?

I'd personally rather see support for commonjs in node_modules. The biggest problem with *.inc.js is that you'll get tons of duplicate sub-dependencies for modules using underscore etc, which is unfortunately quite common.

@shurcooL

Once we add this, it'll be much harder to remove it.

Very true, hence important we give it some thought.

Is there anything similar in the standard Go toolchain? I know it automatically sets build tags for the current Go version, as well as architecture and OS. But is there anything else that it does that would be more akin to the minify flag/build tag?

I very much doubt it, because the Go tool chain works extremely hard to avoid compiler flags. With GopherJS it's more an artefact of the Javascript/web/frontend world that we have the concept of minification and hence the -m flag. Hence I'm not aware of a compiler flag driving a build tag in the Go toolchain.

@tj - not quite sure I understand what you mean. Can you explain more?

The concept of .inc.js and indeed this proposal are intentionally agnostic of any decision to use things like NodeJS/npm etc.

Rather in this case as the writer of a package of GopherJS bindings, I've made an explicit decision that I want to bundle some Javascript (via a package .inc.js) when the bindings are used. In this proposal I'm simply trying to align the bundling of minified production files or development files with the use of the pre-existing -m flag to obviate the user having to explicitly add a build tag which would otherwise be required to choose one or the other (as is currently the case with --tags debug per my example in the description)

Sorry yea wrong place to discuss the inc.js stuff, ignore me :D

I recall a discussion where possibly Rob Pike came down firmly against the suggestion of a build tag for testing mode. I might be able to find it when I am back from vacation in 3 weeks if necessary. But the justification was essentially "code should work the same in production as in testing."

So while a "minify" tag might seem in principle the same as a "test" tag, I'm not sure if that reasoning applies.

Personally, I have little opinion on this matter.

I only wonder if it's worth committing ourselves to supporting this flag essentially forever, only to save a few characters in a few build scripts.

That's actually very similar to the main concern that I've got so far.

Introducing this creates the possibility of someone abusing the minify build tag to have different behavior. As a result, when something goes wrong in minify mode, you will no longer be able to simply turn it off and look at code, because there's a chance the code becomes different without the minify flag.

@flimzy @shurcooL - thanks. Really useful discussion

I recall a discussion where possibly Rob Pike came down firmly against the suggestion of a build tag for testing mode. I might be able to find it when I am back from vacation in 3 weeks if necessary. But the justification was essentially "code should work the same in production as in testing."

I recall having seen a number of discussions along these lines (hence the comment above about compiler flags). And I completely agree with the sentiment.

A few thoughts.

Minification should not, by definition, change the behaviour of Javascript code. At least I assume when we talk about minification in the GopherJS world we're talking about the SIMPLE_OPTIMIZATIONS level of the Google Closure compiler. So the minified code should be identical to the original, modulo identifier and non-significant white space adjustments, just a lot smaller on disk.

So in that respect, the minify flag is not changing the behaviour of our code; to my mind it totally honours the letter and spirit of Rob's comments.

The Facebook strategy of .js files is another matter entirely.

Facebook have two versions of the React .js files:

• development - has some extra runtime warnings/checks etc to warn against probably incorrect behaviour (they mainly have to do this at runtime because there are no static analysis tools that can achieve this)
• production - no additional sanity checks

The development version is somewhat analogous in my mind to the race detector mode of the Go toolchain.

Facebook happen to distribute the development version unminified (to help with debugging) and the production version pre-minified. But the decision to pre-minify the production version is irrelevant; I could just as easily make the decision that I want to minify the development version in my GopherJS app; again, minification doesn't change the behaviour.

So I think the discussion boils down to these two separate points:

1. Do we want to overload -m to in effect be a shorthand for -m --tags minify? @flimzy you're right, it's effectively a convenience thing
2. Is it sensible for Facebook to have their two versions of the React .js files... and therefore is it sensible for github.com/myitcv/gopherjs/react to give the option of which to bundle?

This proposal is about point 1; I'm minded given the discussion to think we probably don't have evidence that the flag set -m --tags minify is sufficiently common to provide a shorthand version, and therefore that we park the proposal for now.

The discussion about point 2 is very valuable. I'll create a separate issue in github.com/myitcv/gopherjs/react world to continue that.

The discussion about point 2 is very valuable. I'll create a separate issue in github.com/myitcv/gopherjs/react world to continue that.

Here is that issue: myitcv#31

This proposal is about point 1; I'm minded given the discussion to think we probably don't have evidence that the flag set -m --tags minify is sufficiently common to provide a shorthand version, and therefore that we park the proposal for now.

👍

Great in which case I close this for now. Thanks again for the fruitful discussion!