Revise/rewrite the build process. "Chipper 2.0"

[samreid]

This is an aggregate issue to identify issues related to wanting to revise/rewrite/extend the build process. We should also create a GitHub label for those issues. Here are additional issues from other repos (not labeled)

https://github.com/phetsims/chipper/issues?q=is%3Aissue+is%3Aopen+label%3Achipper%3A2.0

phetsims/joist#411
https://github.com/phetsims/phet-io/issues/873
https://github.com/phetsims/phet-io/issues/1105
https://github.com/phetsims/phet-io/issues/1149
phetsims/perennial#12

EDIT: @zepumph added the chipper:2.0 label to all other repos.

EDIT: @zepumph: here are all the chipper 2.0 issues.
https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3Achipper%3A2.0+user%3Aphetsims+

[samreid]

We should also create a GitHub label for those issues.

I saw some issues labeled dev:enhancement, not sure if we should co-opt that or create a new one. I guess I'm leaning for a new label.

[samreid]

I started backlinking issues to this one and realized it will be much better if we just start with a label.

[samreid]

In #586 @ariel-phet said:

We should ideally tag open issues that relate to improvements, marking for dev meeting, so we can build up that list.

[samreid]

I marked a few issues for the chipper process (not exhaustive--I may have missed things), generally they fell under categories of:

1. brands, version-id, phet-io
2. getting rid of node_modules
3. streamlining and automating the processes
4. misc

Not sure if this would also be a good time to investigate type checking with flow or typescript.

[zepumph]

Maybe it would be better to have a Milestone for chipper:2.0 instead of a label. Or both?

[samreid]

what are the pros of a milestone?

[zepumph]

A bit easier to track overall progress of all issues, also the ability to track deadlines (not probably important).

I thought of it because the "chipper:2.0" label is in phet-io, joist, and chipper. Based on my understanding of phet's philosophy on labels. They should either be special to a single repo, or in the github label system we have in place in phet-info to make sure that all repos are consistent. To me it felt a bit better to just add the milestone to the few repos that we need. It just only an idea, I don't feel strongly though.

[jonathanolson]

It would also be great to have more flexibility with the dot/kite/scenery builds (e.g. including himlaya in Scenery, so RichText can live in Scenery).

Also, building sun as a standalone would help in tools that use a built version of Scenery.

[jonathanolson]

If we have source-maps working, we can consider transpiling to get ES6+ features in built sims?

[zepumph]

Large chipper:2.0 discussion today during dev meeting:

First there was talk about building phet and phet-io brand together
@samreid says it's a spectrum
easiest: build is a script that says grunt; grunt --brand=phet-io and they are copied to two different places
hardest: re-work the requirejs build to only have to build once, and someone be able to take out the phet-io code if desired.

@ariel-phet thinks it important to try to eliminate as many checklist items from the deployment. Ideally have one command phet-build-and-deploy.

Running a built phetio version with assertions enabled is important, like a devEA or debugBuild version. Will this built version be minified? It would be easier to debug if it wasn't.

@jonathanolson says we don't need a gui right now, but we should emphasize simple command line interface, like scripts that can run all the little steps for us.

Requirements for PhET-iO

• What stuff do we have in a phet-io build that we don't have in the phet build. Can any of that legally be in the phet build?

What about accessibility integrations? Are there build process requirements.
* @jessegreenberg says that screen reader support won't need any chipper:2.0 stuff.
* Does a sonification layer need to be stripped out if still in prototype phase?

[samreid]

We went through the list https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3Achipper%3A2.0+user%3Aphetsims+ and got through about 10 items, stopping around #581 (in that ordering)

[zepumph]

We skipped https://github.com/phetsims/phet-io/issues/1149 though, I don't know how.

[zepumph]

If we have source-maps working, we can consider transpiling to get ES6+ features in built sims?

Today we decided against including source maps in the chipper:2.0 project, instead deferring it, see #602.

[jonathanolson]

I'm at a state where I'm ready to merge in chipper 2.0's branch to master (presumably tomorrow).

I'd like to do this when others are around who can modify supporting code (since the naming/directory changes make it incompatible with other things, including phet-io wrappers/phetmarks/etc.)

I'd also like to consider having someone else to go over a quick review of the changes (what moved to perennial, how the deployment process will work, etc.). @ariel-phet, who would be good to coordinate a review with?

[jonathanolson]

I've applied the necessary changes to bring the chipper 2.0 branch up-to-date with the other changes that were applied on master.

[ariel-phet]

@jbphet will be doing this initial quick review since he is the most familiar other than @jonathanolson with new ES6 features.

[jonathanolson]

I ran through a quick overview with @jbphet, and it seemed that the fundamental changes look reasonable.

Notes before merging chipper 2.0 to master:

• Perennial tasks should be runnable from sim directories (now implemented)
• I should finish more of the cleanup, internal documentation, and external documentation (detailing how to run dev/rc/production deployments, common build commands, etc.)
• build-server changes should be completed so that it is compatible with chipper 2.0 (so when the switch is made, rc/production deployment should work)
• Presumably at a dev meeting, I'll go over the procedures and changes.
• PhET-iO wrapper compatibility (currently on master)

[samreid]

Chipper 2.0 has been working nicely in master for a while now, great work team and especially @jonathanolson, closing.