add export field to package.json

[interim17]

Time Estimate or Size

small

Problem

Installing current viewer version is breaking the website build

It seems the way we are exporting our stylesheet from the viewer, the website bundler can't grab it correctly.
https://webpack.js.org/guides/package-exports/

I was able to inspect /es in the node_modules of the website and see the file we were trying to import, but the bundled website was not including it without the explicit export in package.json of the viewer.

Solution

Adding "exports" field to package.json tells webpack to bundle the stylesheet during website build.

Locally I can test the fix both a dev build via a directory and a .tgz, but I get a little dizzy making changes to both repos, rebuilding, repacking, and reinstalling so I would appreciate a double check, we can also try by just patching the published version.

The unfortunate thing, which I also don't understand, is that this seemed to trigger some breakages in the typing on our styled components in the website.

I have no idea why, it does make sense because we had a mismatch in our v6 styled-components and @types/styled-components version, but I don't know why the viewer build seemed to trigger it.

PR to fix website:
simularium/simularium-website#649

When we publish the viewer patch, I will install it on that branch, and then hopefully we will see a successful website build.

• Bug fix (non-breaking change which fixes an issue)

Final confirmation will be a successful website build with the ability to alt-ctrl-1 to see the advanced controls.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	22.15%	2583 / 11657
🔵	Statements	22.15%	2583 / 11657
🔵	Functions	25%	149 / 596
🔵	Branches	80.41%	349 / 434

File Coverage

No changed files found.

Generated in workflow #611 for commit ab61007 by the Vitest Coverage Report Action

[ascibisz]

this looks good to me! thanks for the quick turnaround on the fix

[toloudis]

this is odd to me because of the "files" section above, that has both "es" and "style" in it.. it looks like this is pushing es/ up one level relative to style/

[interim17]

Oh you're right, so this branch is currently putting it at the top level and in /es. The /es one has always been there but webpack wasn't using it. It works...

But I found another way to fix it which is to just import import "./style/style.css"; in src/index.ts...

Feels too simple, so I'm going to keep rebuilding and repacking and re installing until I'm sure but it seems like the better way to do this.

[interim17]

Importing the stylesheet into index.ts: locally the builds, installs and tests are working, but CI tests fail to resolve import.

It's notable to me that Vite building the test bed resolves the import just fine where webpack for the website doesn't. I'm down to look at the simularium website moving to Vite, or otherwise tweaking that build, but I won't be able to get that done today.

Current patch option that makes simularium website build happy is the "exports" field with styles at both levels. or leave this open for a minute

[interim17]

@meganrm @toloudis

Here is my best-thought/understanding about this issue and how to resolve it.

Issue 1: When we switched to ES modules, #431, we broke imports that were not in es/index.js, because we were not including them specifically in "exports" field. Including the files is not enough to tell bundlers that those imports are allowed when using ES modules.

Issue 2: We thought we fixed that by putting stylesheet in /es during processCss script #456
That only fixed the test bed because of local alias of of /es in vite config, and resulted in duplicating the stylesheet in production build when we released 3.10.0. Testing local builds for website seemed to work because we structured the output directory differently than in CI/CD.

My proposed fix in commit ab61007:

• Remove top level style directory from "files" in package.json and from copy-build script
• Put the stylesheet into es/style/style.css during build and then copy the whole directory when running copy-build (used in publishing/CI/CD)
• Alias in exports field so that imports are backwards compatible with docs and previous published packages:

    "exports": {
        ".": "./es/index.js",
        "./style/style.css": "./es/style/style.css"
    },

allows this import to resolve: import @aics/simularium-viewer/style/style.css

Pros: There is no duplication of stylesheet, uses exports field which should have been part of our ES migration, installing local build folder resolves the same way published packages do.
I have tested it with test-bed installing file:../ aka local build, as well as with test-bed and website installing a packed .tgz
Cons: Someone inspecting their installed node_modules might be confused to see that they can import @aics/simularium-viewer/style/style.css but not see that directory at that level, and they would not understand why that resolves unless they looked in more detail at package.json exports field.

Final proof will be to release a patch and install it in the website to make sure that CI/CD pipeline is also happy.

[toloudis]

Seeing this makes me wonder if you could have the same effect if you just had one single export alias from "." to "./es"

[interim17]

Possible, and I could test that if you like, but I think that would allow importing from everything in /es rather than just the stuff we choose to expose in index.js?

[toloudis]

okay, then in that case I think I like your fix as is, assuming it works in all the cases we care about! Or if @meganrm has any better ideas

[toloudis]

I'd love an elegant thing that doesn't really require special export aliasing config, but I'm happy this makes things work