sethbattin / bundle-report Goto Github PK

Our bundle file names include the webpack hash. We use globs to specify which files are checked. But the output is based on the full name. This takes up too much space with unhelpful information. It also makes comparing builds difficult.

We want to allow the reported file name to be a shorter version. Some kind of filter pattern for all files or for specific entries. This shorter name should be used in the report output and data. Something like this:

"./build/assets/vendor-0b7ec4eebf367780b1a3.bundle.js" => "vendor"
"./build/assets/healthCheck.0b7ec4eebf367780b1a3.js" => "healthCheck"

When the build size is exceeded, the error handling causes incomplete data to be generated. This causes an invalid status link, which looks like a server error on the bundle-size storage app.

Revise error handling so that complete data is generated and the links work even for failed checked.

I have seen eslint-plugin-standard and eslint-plugin-prettier conflict with each other. We also have prettier as a dev dependency.

prettier can do all the jobs. let's purge eslint and kin.

Put the build results into the PR comment thread. We'd like to see the current build compared to the target branch. Something like:

The existing statuses have json data containing the results for branches. We might be able to sample that to create the table. #9 might be a prerequisite for this, so that the names have something reliable to compare build-to-build.

The tarball experiment seems to have worked, so it's public npm time.

When running npm pack, a script runs to exercise the build to assure it works. https://github.com/sethbattin/bundle-report/blob/parallel-dev/scripts/testPack.sh

This script failed to detect the lack of the js-yaml lib that was resolved in https://github.com/sethbattin/bundle-report/releases/tag/v1.2.1

The pack script should run using all the configuration options to assure every one is functional.

Add tests to excerise the CLI. Perhaps use the execa lib, as described in siddharthkp#112

Currently this lib adds builds status via github-build, which does exactly one task. It can POST a status to a specific repo/ref using a token. It also doesn't support github enterprise, which is an unresolved issue, siddharthkp/github-build#5. Some other people have already written a replacement from scratch, which is feasible because the lib is so simple.

But instead of reinventing the wheel, we could use an existing system.

We should replace it with a wrapper of node-github. That will let us other API methods (e.g. GET status), as well as allow github enterprise to work.

Feature

In addition to the CLI options and the package.json object, we should permit loading a configuration file.

• Open-ended configuration
• Tidy package.json
• Clean CLI
• Settings in version control

Requirements

Comments welcome :)

1. In the absence of any CLI arg or package.json setting, we should check for a default config file such as .bundlesize.rc.
2. Create an in-repo default config, and use that in place of hardcoding the defaults into config.
3. The CLI should accept a -c, --config [config] option and try to read it (also format inferred or agnostic).
4. Check if package.json's bundlesize key is a string, and if so try it as a file path.
5. Check the bundlesize object property in package.json for a key 'config'. If there are other config settings there, merge the file settings over the package.json settings (allows local overrides)

File format

Any of these:

• JS module
• JSON
• yaml
• other?

I vote for being format agnostic. If the file name extension isn't obvious, we should try/catch js and json via require, yaml via a yml loader, and {other} via whatever is appropriate. If we're taking a customer's file and parsing it, we can try to guess correctly based on extension and save a few caught exceptions.

The script bundle-report-init sends an "in-progress" status to the current CI commit, so that it appears as a placeholder. This is useful for when the build takes a long time, so that the status is present before the build finishes.

If the build fails, we want to mark this status as failed, but currently there is no entry point for that. We should add one