Moving utility scripts to fp-ts-scrips

[IMax153]

@gcanti - For a while now, I have felt like the various utility scripts used in the fp-ts ecosystem libraries should live in their own centralized repository/library (i.e., build, release, import-path-rewrite, etc.).

I created fp-ts-scripts as a proof-of-concept. Take a look and let me know if this is something you think would be of interest. If so, I can start adding tests, better documentation, and more feature rich logging.

[gcanti]

@IMax153 I'm interested in something centralized for the next generation (fp-ts@3, io-ts@3, etc...) I definitely want a standard build / release process for them (maybe based on build2.ts in the 3.0.0 branch).

Currently the scripts I'm using are semi-standard: they are customized here and there to accomodate small differences in some libraries:

• fp-ts: semi-standard + custom HKT handling
• io-ts: semi-standard (no custom HKT handling)
• monocle-ts: semi-standard + custom nested folders handling (no custom HKT handling)

[IMax153]

This makes sense to me - the build process for each lib will differ and scripts may need to be customized.

The nice thing about the framework I set up in fp-ts-scripts is that each script (i.e., build, release, import-path-rewrite, etc) is a separate CLI command which can be executed with various options to customize its behavior (or just used with the defaults).

For example, currently running

yarn fp-ts-scripts build --copy-files CHANGELOG.md LICENSE README.md --mainDir lib --moduleDir es6 --output-dir dist

is equivalent to running

yarn fp-ts-scripts build

If additional configuration for is necessary, the corresponding [Script]Options and makeCommand function can be updated to add additional CLI options.

However, I will take a look at build2.ts in the [email protected] branch. I'll also look at the other libs and see what configuration is truly necessary for each script. The naming of CLI arguments is also not that great right now, so I'll try to improve that as well (i.e., --mainDir vs --es5).

[gcanti]

If I started a fresh project I'll definitely use something like build2.ts (the current scripts must account for legacy lib / es6 folders and I don't think it's worth touching them)

[IMax153]

I’ll keep that in mind as I iterate on the project. I’ll post again here once I’ve made some updates to the repository.

[waynevanson]

We should definitely a design document for something like this.
A summary of constraints with explanations detailed later within.

I like this by the way, great to see!

[IMax153]

Great idea @waynevanson - I think a simple design document detailing the requirements will be helpful as the lib is iterated upon. I can create something in the lib next time I work on it and we can all contribute if we choose to.

[IMax153]

@gcanti - I've done a bunch of work to the build script in fp-ts-scripts. I tried to mirror the new build process in the 3.0.0 branch of fp-ts.

I was hoping you could take a look at the changes, as well as the design document discussion and let me know your thoughts. The design document outlines the purpose and usage for each of the scripts in the library.

Note: If and when the library is prepared for publication, there will not be an es6 build included. I only included it for the purpose of testing for the moment. There is a lot of other cleanup that needs to be done, but I figured that the design should be ironed out and agreed upon first.