Clean publish and eject

[Jiansen]

• separate dev config and prod config, including paths.js
  • part of Unroll indirection in paths #191
• cleanup code on eject
  • same as in eliminate dev-only code on eject #53 #191 #206 , can close 206 if this PR is accepted.
  • as discussed in eliminate dev-only code on eject #53 #191 #206, the --smoke-test tag is kept in production code for now
• on release, only ship configurations for production code
  • in the node_module installed at users side, there will be no --debug-template flag
• same as above, in e2e test, when testing cli, only pack production code
• on local dev (i.e. build and start), use dev configuration

Disscussion 1: add parameter stage to pack.sh so that

• pack.sh prod only ship prod configurations
• pack.sh dev only ship dev configurations
• pack.sh test only ship test configurations
• etc.

This can be done by removing files in package.json, and creating a few versions of .npmignore files (e.g. .npmignore.prod).

Disscussion 2: further split paths.prod.js to 2 files, paths.beforeEject.js and paths.afterEject.js; remove the // Dead code on eject:start/end block.

Question:
start.js always use the dev config for webpack. Is there a reason for this? In my local test, it seems fine to use production config in a generated app.

[Jiansen]

Don't merge for now.

I found this in CI build console. e2e isn't completed there. Might suggest another issue to fix.

++++tasks/pack.sh
tasks/e2e.sh: line 50: tasks/pack.sh: Permission denied

[vjeux]

You probably want to chmod +x tasks/pack.sh

[Jiansen]

@vjeux ,

Yes, I checked the permission on my local machine, it has +x permission. git status doesn't show anything to commit. If permission change is not picked by git, I will probably delete and re-add the pack.sh file.

Thankfully, the last build (222.1) looks OK.

[gaearon]

I’m worried that this convention is going to look super confusing to people after ejecting (or even for those who want to contribute to this project). What alternative solutions have you considered?

[Jiansen]

I agree that the code is confusing to some extent. In fact, I leant very recently that require looks for index.js when the required path is a folder.

Two ideas:

1. replace it with require('../config')('paths'); even if the file is in the same folder. At least the word config appears in the code to suggest the meaning of this line.
2. create a symbolic name config so that the above code is rewritten as require('config')('paths').

I don't know how to do 2 honestly. I will take a look at this method and search for others.

There is another decision worthy a discussion: should config/index.js export a function (like the current change) or an object with fields like paths and so on.

It is more conventional for a module to export an object or a constructor. But exporting a function has advantages in this case:

1. the code is short, and we don't need to introduce a new field every time when a new configuration is introduced; simply create a *.prod|dev.js file.
2. we could add an error message/exception when developers made a typo on importing a configuration, let the typo be exposed earlier.
3. in test/dev, we are still able to import a prod config (e.g. the current build.js always uses webpack.prod)

[gaearon]

Looking at this, I think we should keep it simple and not mess with the filenames.
If paths.js is the only thing that really needs branching, let’s just do something like

// paths.js

module.exports = {
  // ejected paths
}

// @remove-on-eject-begin
if (...) {
  module.exports = // local dev paths
} else if (...) {
  module.exports = // dependency paths
}
// @remove-on-eject-end

[Jiansen]

If paths.js is the only thing that really needs branching ...

Changes in this PR cut off code at 2 places

1. when pack/publish the project as a npm module
2. when a user runs eject

If we don't do 1, then dev-only flags like --debug-template are still available to users, though they need to dig a bit into the source code of this open source project :p

I like your syntax of // @remove-on-eject-begin/end. I will refactor code in PR #206, which only does 2. We could review if features in the top comment are needed or not, and update the code accordingly.

[gaearon]

We can do (1) with separate flags.
Maybe something like:

// paths.js

module.exports = {
  // ejected paths
}

// @remove-on-publish-begin
if (...) {
  module.exports = // local dev paths
}
// @remove-on-publish-end

// @remove-on-eject-begin
if (...) {
  module.exports = // dependency paths
}
// @remove-on-eject-end

[Jiansen]

Yes, merging *.prod.js file and *.dev.js into one file is a good idea for code maintenance.

I will try later today or over this weekend. Thanks for your advice.

[Jiansen]

Refactored and rebased previous changes as suggested. To summarise

• tag dev-only code with // @remove-on-publish-begin/end tag
• tag pre-eject-only code with // @remove-on-eject-begin/end tag

As per the support of the above 2 tags, if code looks OK, this PR is ready to be merged.

If we wanted to merge babel.[prod|dev].js and webpack.config.[prod|dev].js as well, I have 2 questions

1. *.prod.js contains some code that is not in *.dev.js
2. Currently build.js always uses webpack.config.prod whereas start.js always use webpack.config.dev

// `build.js`
var config = require('../config/webpack.config.prod');

// `start.js`
var config = require('../config/webpack.config.dev');

In an earlier test, it seems fine to let start.js uses prod config in production environment. I haven't tested if build.js could use dev config in local development environment.

I will search for webpack related issues and PRs to understand why those two files are tied to specific configurations (runtime/build efficiency?). If someone has a short answer, or knows the reference to a related issue/PR, please let me know.

[gaearon]

Can you please use the same error handling mechanism that e2e test now uses?

[gaearon]

I left a few final comments, I think it’s good to go when they are addressed.
Also please rebase, it doesn’t merge now.

[Jiansen]

@gaearon , I rebased as suggested.

Do you think we should use the same error handling mechanism in release.sh as well, or run e2e at the beginning, or assume project will always properly tested before a project admin runs release.sh?

[Jiansen]

Rebased.

@gaearon , do you plan to add this PR back to milestone 0.3.0, if not merging it soon?

Currently, minor changes to config/paths.js will cause code conflicts due reordering of configs. I don't mind to rebase again when it is a good time to deliver. Just curious about the plan.

[gaearon]

Let’s get this in and maybe iterate on it later.
Thanks.

[gaearon]

This is really nice. 👍

If you’d like, please feel free to make a followup PR to make eject result more natural.

For example I think it might make sense to try to write babel.dev.js and babel.prod.js without all those crazy require.resolves and then put the require.resolve mapping behind an // @remove-on-eject.

[Jiansen]

@gaearon , good point. I will try as you suggested.