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

webpack: lockdown inlining #1101

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

webpack: lockdown inlining #1101

wants to merge 5 commits into from

Conversation

naugtur
Copy link
Member

@naugtur naugtur commented Mar 13, 2024

Some use-cases (including snaps) need to inline SES lockdown into the bundle file. It's impossible to flawlessly guess which file will be the one to load first on a new page in more complex configurations, so I went with a static list you have to provide. separate file lockdown remains the default approach.

Updated the README with explanation of this and got it up to date with implementation,

@naugtur naugtur requested a review from a team as a code owner March 13, 2024 11:39
@github-actions github-actions bot added documentation Docs, examples, tutorials, and associated tooling pkg:@lavamoat/webpack Changes in package @lavamoat/webpack labels Mar 13, 2024
packages/webpack/README.md Outdated Show resolved Hide resolved
packages/webpack/README.md Outdated Show resolved Hide resolved
- The plugin is attempting to add it as an asset to the compilation for the sake of Developer Experience. Feedback welcome.
- [SES lockdown][] must be added to the page without any bundling or transforming for any security guarantees to be sustained.
- The plugin is attempting to add it as an asset to the compilation for the sake of Developer Experience. `.js` extension is omitted to prevent minification.
- Optionally lockdown can be inlined into the bundle files. It's hard to determine which files are loaded when, so providing filenames for scripts that get to load as the first script on the page to apply lockdown only once is how one uses inlining.
Copy link
Contributor

Choose a reason for hiding this comment

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

This sentence is a little hard to understand

Copy link
Member Author

Choose a reason for hiding this comment

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

It was even harder to write 😅

packages/webpack/src/plugin.js Outdated Show resolved Hide resolved
packages/webpack/src/types.js Outdated Show resolved Hide resolved
Comment on lines +9 to +11
await t.notThrowsAsync(async () => {
t.context.build = await scaffold(webpackConfig)
}, 'Expected the build to succeed')
Copy link
Contributor

Choose a reason for hiding this comment

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

the side-effect here is little malodorous to me, but I'm not sure what a better solution would look like.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm not sure what you mean is a side effect here. scaffold is running the build and returning information it collects. If it fails, we report it as a testsuite failure.

naugtur and others added 2 commits March 22, 2024 15:29
- The plugin is attempting to add it as an asset to the compilation for the sake of Developer Experience. Feedback welcome.
- [SES lockdown][] must be added to the page without any bundling or transforming for any security guarantees to be sustained.
- The plugin is attempting to add it as an asset to the compilation for the sake of Developer Experience. `.js` extension is omitted to prevent minification.
- Optionally lockdown can be inlined into the bundle files. It's hard to determine how entries in the config are deployed and used, so you need to list the scripts that get to load as the first script on theDo we have page to apply lockdown only once when inlined. When you have a single bundle, you just configure a list with one element. It gets more complex with builds for multiple pages.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
- Optionally lockdown can be inlined into the bundle files. It's hard to determine how entries in the config are deployed and used, so you need to list the scripts that get to load as the first script on theDo we have page to apply lockdown only once when inlined. When you have a single bundle, you just configure a list with one element. It gets more complex with builds for multiple pages.
- Optionally, lockdown can be inlined into the bundle files. The user is expected to provide a list of the scripts allowed to load as the first script on the page.

The rest of the text doesn't really seem relevant for the user (and the "single-item-can-be-provided-as-single-element-list" should be obvious)

Copy link
Member Author

Choose a reason for hiding this comment

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

While the wording could be better (and I can see a copy-paste error now), I insist on explaining that we can't simply infer this from the webpack configuration and need the user to specify files to inline into.

Copy link
Contributor

@legobeat legobeat Apr 15, 2024

Choose a reason for hiding this comment

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

I think it's enough to make it clear that we need the user to specify the files - alluding to our perceived difficulty in automatically deriving it isn't really helpful and comes off at an attempt at an excuse at best and confusing at worst (:

Copy link
Member Author

Choose a reason for hiding this comment

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

It is an excuse for the folks with a basic setup where there's only one resulting bundle file that I decided not to support for consistency. Wanna change that?

Copy link
Contributor

@legobeat legobeat Apr 15, 2024

Choose a reason for hiding this comment

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

I think the behavior is fine and I agree we should make it clear what configuration is required. But let's stick to the point and keep any discussion of implementation difficulties in developer docs as opposed to readme?

Co-authored-by: legobeat <109787230+legobeat@users.noreply.github.com>
Co-authored-by: Christopher Hiller <boneskull@boneskull.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Docs, examples, tutorials, and associated tooling pkg:@lavamoat/webpack Changes in package @lavamoat/webpack
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants