Create jasmine-parameterized package

[mollykreis]

Pull Request

🤨 Rationale

This is part of #1551

Based on this discussion, we decided to create a new npm package for jasmine-parameterized rather than have it be exported from an existing nimble package.

👩‍💻 Implementation

• Create a new package called jasmine-parameterized that contains the existing parameterized.ts and tests\parameterized.spec.ts
• Add appropriate support files to build, lint, and test the package
• Delete parameterized.ts and tests\parameterized.spec.ts from nimble-components
• Update the tests in nimble-components to use parameterizeSpec from jasmine-parameterized

🧪 Testing

• Verified that the jasmine-parameterized tests are run in the pipeline
• Verified that the jasmine-parameterized package contains the dist directory (without tests), package.json, and README.md
• Verified all nimble-components tests still pass

✅ Checklist

• I have updated the project documentation to reflect my changes or determined no changes are needed.

[mollykreis]

@msmithNI, can you buddy this PR for me?

[rajsite]

Thinking about the API a bit, I think we should make the following changes:

• Don't expose the parameterize helper function (i.e. don't export it or put it in the readme) and rename parameterizeNamedList to parameterizeSpec
• Make it so the import is top-level in the package, i.e. import { parameterizeSpec } from '@ni/jasmine-parameterized';. This should be doable with conditional exports for import and require: https://nodejs.org/api/packages.html#conditional-exports
• We create the cjs build and we should test it in node
  • See how the xliff package uses the jasmine node cli:

    nimble/packages/xliff-to-json-converter/package.json

    Line 18 in aa6943c

    "test": "jasmine"

  • And configures the node tests: https://github.com/ni/nimble/blob/aa6943c5910766f77c69a47bee2406e6210ac8ce/packages/xliff-to-json-converter/spec/support/jasmine.json
  • jasmine runner docs: https://jasmine.github.io/setup/nodejs.html

It shouldn't be in this PR but this allows us to make something like parameterizeSuite to align with parameterizeSpec in the future, something like:

const sizes = [
    { name: 'small', value: 2 },
    { name: 'medium', value: 5 },
    { name: 'large', value: 10}
] as const;
parameterizeSuite(sizes, (suite, suiteName, suiteValue) => {
  suite(`A ${suiteName} rain`, () => {
     const rainTests = [
          { name: 'cats-and-dogs', type: 'idiom' },
          { name: 'frogs' type: 'idiom'},
          { name: 'men', type: 'lyrics'}
      ] as const;
      parameterizeSpec(rainTests, (spec, name, value) => {
          spec(`of type ${name} exist`, () => {
              expect(value.type).toBeDefined();
              expect(suiteValue.value).toBeDefined();
          });
      }, {
          'cats-and-dogs': fit,
          frogs: xit
      });
  });
}, {
  small: xdescribe
});

[mollykreis]

Don't expose the parameterize helper function (i.e. don't export it or put it in the readme) and rename parameterizeNamedList to parameterizeSpec

I've renamed parameterizeNamedList to parameterizeSpec. I also no longer am exporting parameterize or including it in the readme. However, my question is: Should we remove parameterize altogether? It isn't used by anything.**

Make it so the import is top-level in the package, i.e. import { parameterizeSpec } from '@ni/jasmine-parameterized';. This should be doable with conditional exports for import and require: https://nodejs.org/api/packages.html#conditional-exports

Done, but let me know if there is something I should've done differently.

We create the cjs build and we should test it in node

Done. I also updated karma.conf.json to only run tests on the esm build, but should karma.conf.json still be configured to run for both esm and commonjs?

[rajsite]

Should we remove parameterize altogether? It isn't used by anything.**

It is used in the parameterizeSpec implementation. Don't think I follow what is being proposed.

nimble/packages/jasmine-parameterized/src/parameterized.ts

Line 125 in 7be0f7c

parameterize<ObjectFromNamedList<T>>(testCases, test, specOverrides);

Done. I also updated karma.conf.json to only run tests on the esm build, but should karma.conf.json still be configured to run for both esm and commonjs?

Was mulling over it a bit and realized that the browser usage was being pushed through webpack, so it was really testing the webpack config and the node usage wasn't relying on the cjs import as the test file itself was using the es6 import statement to reference the dependency instead of the cjs format require statement.

Modern versions of browsers and node support es6 modules so I simplified and removed the cjs parts of the build. I switched the TS config to use the newer "Node16" for the module format (which is just es6 modules as supported by node).

So now we are actually using esm js files and I got esm tests to work in karma .

I also read the npm entrypoints and typescript npm entrypoint docs and modified the format of the entrypoints to match that. For some reason I needed the Fall-back for older versions of TypeScript that I couldn't figure out but guess it's not a big deal.

[mollykreis]

Thanks for the updates to the branch!