Standalone content-tag implemented via conditional exports in package.json

[NullVoxPopuli]

Alternative to: #41

Changes:

• there are now two wasm-pack builds, one targeting noed, and one "browser" or "standalone" (as browser targets tend to be "standalone" / runnable anywhere) -- if we didn't need to support CJS, we could get away with only the standalone build
• the root package.json is now the package.json that is published
  • now has name, description, etc
  • files entry includes the pkg directory
  • has exports with conditional/subpath entries to target node/browser separately since wasm-pack generates very different output for each target (there isn't a need for this if they went for full async-only API, but 🤷 )
• To test that the browser changes actually work, vite has been added to devDependencies as well as an index.html
  • I tried to automate browser testing with vitest's browser mode: https://vitest.dev/guide/browser#browser-option-types -- but the browser mode does not support the same work around that vite has for Packages using self-referencing imports will fail to resolve ("moduleResolution": "node16" and package.json "exports") vitejs/vite#9731 -- which is setting resolve-alias for "package-name": "." (current directory) so that vite can resolve the "self's" exports. So we currently don't have automated browser testing atm. We could set up qunit instead of vitest, but we currently need to handroll a reporter to the CLI, because vite/vitest haven't given us those APIs to build custom reporters. GlimmerVM is already doing this, so it "just" needs to be extracted.
    This is the error:

    [plugin:vite:import-analysis] Failed to resolve import "content-tag" from "test-browser/process.test.js". Does the file exist?
    /home/nvp/Development/OpenSource/emberjs/content-tag/test-browser/process.test.js:2:48
    1  |  import { __vi_inject__ as __vi_esm_0__ } from 'vitest'
    2  |  import { __vi_inject__ as __vi_esm_1__ } from 'content-tag'
       |                                                 ^
    3  |  
    4  |
    

  • Due to not being able to correctly test with vitest, I added publint and @arethetypeswrong/cli to help me be more confident that the package.json was correctly configured so we don't have to rapid publishes to fix bugs with package.json config.
    @arethetypeswrong/cli reported some issues which are resolved now.
    One being this issue which is resolved by using node newer than 16 -- which... we don't declare node support at all, and node 16 is EOL'd so it seems fine to bump the CI's node.

---

In a real app

because my confidence in non-monorepo layouts is way lower (can't test with real projects with real module resolution),

here is a real usage:

• branch with dist assets committed: https://github.com/NullVoxPopuli/content-tag/tree/non-monorepo-dist
• PR to my repl here: content-tag PR https://github.com/embroider-build/content-tag/pull/44 NullVoxPopuli/limber#1546
  Results:
  • Works:

    let processor: any;
    let fetchingPromise: Promise<any>;
    
    export async function preprocess(input: string, name: string): Promise<string> {
      if (!fetchingPromise) {
        fetchingPromise = import('content-tag');
      }
    
      if (!processor) {
        let { Preprocessor } = await fetchingPromise;
    
        processor = new Preprocessor();
      }
    
      return processor.process(input, `${name}.js`);
    }

  • Does not work:

    import { Preprocessor } from 'content-tag';
    
    const processor = new Preprocessor();
    
    export async function preprocess(input: string, name: string): Promise<string> {
      return processor.process(input, `${name}.js`);
    }

    but this is due to:
    top-level-await causes component loading to break embroider#1678
    and this code likely would work once that 1678 issue is resolved.

[NullVoxPopuli]

the root package.json now is the package.json that is published. previously, a separate package.json was used

[NullVoxPopuli]

this conditional export is what enables browser mode

[NullVoxPopuli]

(assuming vite isn't falling back to the "default" exports (pkg/node/content_tag.cjs) and polyfilling all the node stuff for the browser)

[void-mAlex]

would be nice to have this consistent with release workflow

[NullVoxPopuli]

the release workflow already run npm run build, so this is covered

[void-mAlex]

yes, if this did the same thing meaning npm run build the two would be in sync

…

On Fri, Dec 1, 2023, 22:58 NullVoxPopuli ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In .github/workflows/ci.yml <#44 (comment)> : > cache: 'npm' - - run: npm ci + - run: ./build.sh the release workflow already run npm run build, so this is covered — Reply to this email directly, view it on GitHub <#44 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHPNIYA6WWEOZLJLNEWL23YHJOHRAVCNFSM6AAAAABADKFMUKVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTONRQGY3TGMJTGM> . You are receiving this because you commented.Message ID: ***@***.***>