how remove debug info from react.min.js file when publish project

[behnammodi]

how remove debug info from react.min.js file when publish project

[gaearon]

This is because these lines are the last argument rather than the second "message" argument to invariant so they don't get cut out automatically.

If you'd like to fix it, please submit a PR that splits this into several invariant calls with different messages, and check if this makes the build size smaller.

[behnammodi]

my proposal use message map in apart js file
message map easy use in debug mode and easy remove when publish
create all message with code for example

message={
    1: 'this is a sample message',
    2: 'this is a sample message 2',
    3: 'this is a sample message 3',
    ...
};

then use reactjs with message code.

[gaearon]

We already do exactly what you suggested. It's done automatically when you use invariant and pass string as a second argument. A Babel transform extracts second "message" argument. However this doesn't happen for any other arguments, which is why I suggested making multiple invariant calls.

[rickbeerendonk]

We are talking about react-dom.min.js, not react.min.js.

The gulp script (bfd1531) extracting the error-codes is not part of the build, so it had to be run separately.

Doing what @gaearon said will actually make the minified version 19 bytes larger when I change the lines in ReactMount.js.

There are currently more error-codes not part to codes.json, so we should gain in other places.

Will continue on this tomorrow.

[rickbeerendonk]

Cleaning up the code table will bring down the size of react.min.js and react-dom.min.js. However, numbers in the code table should not contain gaps and renumbering causes tests (that depend on those numbers) to fail. I'll fix those too.

[keyz]

@rickbeerendonk it's been fixed in #7999 but improvements are welcome.

[rickbeerendonk]

@keyanzhang I'll have a look.

[rickbeerendonk]

Conclusion:

• There are 7 invariants with a second argument ending with ".%s", meaning there is text in the 3rd argument and the minified files. Changing the code to turn those into resources (if possible) increases the size of the minified files.
• codes.json is missing error messages (fixed in Fix error codes #7999)
• codes.json container old error messages. Cleaning will remove 126 bytes from react.min.js and 22 bytes from react-dom.min.js
• Removing unused error messages from codes.json will make unit tests fail due to required renumbering. Fragile.
• gulp task react:extract-errors does only add error messages and doesn't remove old/unused messages. Cleaning those messages however will gain bytes in minified files. Should be a new issue?
• gulp task react:extract-errors does not find all error messages (build will have messages "Error message "Item must have been set" cannot be found. The current React version and the error map are probably out of sync. Please run gulp react:extract-errors before building React.")

@gaearon @keyanzhang
I'll submit a pull request with an updated codes.json where old messages are removed as this is reducing size of minified files and is not a job that gulp task react:extract-errors is doing.
I propose not to do anything with this issue itself because changing the code will only increase the minified files.

[keyz]

Thanks for your contribution! However, codes.json should not be manually edited. This file is designed to be append-only to ensure backward compatibility, which means an existing code in the file will never be changed/removed. The README file added in #7999 contains more information about the system. The gulp task has also been fixed there.

However, it's interesting that you mentioned removing old messages from codes.json actually decreases the build size. Could you tell me more about this? The json file is only used as a reference and not included in a release build so I'm not sure why this happens.

[rickbeerendonk]

@keyanzhang The backwards compatibility is a bit hidden in the docs. It's due to having a central system for all error messages for old past versions?

[keyz]

@rickbeerendonk Yeah, exactly. It should not affect the build size though.