Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(rollup, webpack): print license in bundled file #2487

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

joannacirillo
Copy link
Contributor

Results

Configuration of Webpack and Rollup have been updated to write license file content in bundles (in prod and dev builds) for esm and umd builds.

  • semantic-release commit messages
  • Run npm run reformat to have correctly formatted code

@finetjul finetjul requested a review from floryst June 22, 2022 13:47
Copy link
Collaborator

@floryst floryst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The output matches expectations, so that's good!

Do we care about preservation of the vtk.js license in downstream app bundles? If so, we will need to start the license block with a /*! . Additionally, one concern I have with the ESM build is the potential for the license to be replicated many times, once per unique vtk.js import. This will have to be tested to be sure.

rollup.config.js Outdated
Comment on lines 70 to 75
intro() {
return `/* ${fs.readFileSync(
path.resolve(__dirname, './LICENSE'),
'utf8'
)} */`;
},
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is intro() called once overall, or once per file? If the latter, it's best to not have the overhead of reading the LICENSE file multiple times. If just once overall, then this is fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is run for the output for which it is in the output options so here for all outputs in outputdir. I'll make an update for that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The license is printed only in vtk.js file now. However, I did not get to do it without creating another entry/output "rule" for that.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI the vtk.js file isn't the ESM build's entrypoint. I think it's the index.js file. That being said, the import strategy we have doesn't go through a single file, so we would need to consider how we want the vtk.js license to show up in downstream builds.

@finetjul would we consider a single license header in the vtk.js file to be sufficient? Or in each outputted .js file? We would still have the issue of preserving the license header if we output to each .js file, but we may not have any such license header if the user doesn't include vtk.js.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@finetjul so currently the license is printed in the vtk.js file but as said by Forrest, if the user does not include the vtk.js file it will not be written.

webpack.common.js Outdated Show resolved Hide resolved
@joannacirillo joannacirillo force-pushed the print-licence-build branch 3 times, most recently from ee740ba to 7b3df29 Compare June 23, 2022 13:02
rollup.config.js Outdated
format: 'es',
hoistTransitiveImports: false,
intro() {
return `/* ${fs.readFileSync(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to preserve the license in downstream apps that build using vtk.js? This is typically accomplished via /*! or a line with @license.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needing to preserve will complicate how we get it to be preserved...

@joannacirillo joannacirillo force-pushed the print-licence-build branch 2 times, most recently from dd0ad9a to d61afc6 Compare July 1, 2022 07:59
@jourdain
Copy link
Collaborator

Lot's of fix(). If it is affecting only the build should those changes not trigger any new release?

@joannacirillo
Copy link
Contributor Author

Lot's of fix(). If it is affecting only the build should those changes not trigger any new release?

My bad, it should be build commits, only one commit in the end even.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants