Add exports to package.json to restrict access to private internals

[bmish]

https://nodejs.org/api/packages.html#exports

This prevents users from importing files directly from this package.

ESLint v8 also added this restriction.

Beginning in v8.0.0, ESLint is strictly defining its public API. Previously, you could reach into individual files such as require("eslint/lib/rules/semi") and this is no longer allowed. There are a limited number of existing APIs that are now available through the /use-at-your-own-risk entrypoint for backwards compatibility, but these APIs are not formally supported and may break or disappear at any point in time.

Ideally, we'll hear from users after making this change if there are additional internals that we need to expose as part of our public NodeJS API in lib/index.js.

Part of v4 release (#1908).

TODO:

• Expose generateRuleTests as named export in public NodeJS API #2209
• What to do about users who may need to retrieve the default config from no-bare-strings? const { DEFAULT_CONFIG } = require('ember-template-lint/lib/rules/no-bare-strings'); Change no-bare-strings rule options to augment instead of replace the default config  #2213

[dcyriller]

I think we will need to expose lib/helpers/rule-test-harness.js as well. It is used by the plugins to test their rules (example).

But maybe it is the good time to expose it through lib/index.js? Wdyt?

[bmish]

Good point, my preference would be that we expose that through lib/index.js, as I've implemented here: #2209

[bmish]

I added to the description of this PR that there's another item we need to solve:

What to do about users who may need to retrieve the default config from no-bare-strings? const { DEFAULT_CONFIG } = require('ember-template-lint/lib/rules/no-bare-strings');

[dcyriller]

What to do about users who may need to retrieve the default config from no-bare-strings? const { DEFAULT_CONFIG } = require('ember-template-lint/lib/rules/no-bare-strings');

It is difficult to tell if the default config from no-bare-strings is really consummed by some ember-template-lint plugins. TBH I have no idea.

I see two options:

• we don't expose it and wait for users to report an issue if they need it;
• we expose it through the lib/index.js file. This option has the advantage of being more gentle (no bug, no issue to report) but the drawback of increasing the cost of maintenance of ember-template-lint (# of files exposed, etc.)

I see your PR as the opportunity to keep the API surface under control. Then, I would not expose the default config from no-bare-strings. But maybe there are other opinions.

[bmish]

@dcyriller thanks for the feedback. I agree we should avoid exposing things unnecessarily.

I'm going to redesign the no-bare-strings rule configuration a bit so that there's no need for consumers to import the default config from the rule. The new behavior of the rule options will be to augment instead of replace the default config, as augmenting is typically what consumers want to do. If anyone really needs to replace the default config, then we can add boolean options to the rule ignoreDefaultAllowList, ignoreDefaultGlobalAttributes, ignoreDefaultElementAttributes (default false) to get the old behavior back.

[dcyriller]

I see, thanks for the explanation. I gave it a try in the linked PR.

[dcyriller]

FYI I noticed ember-template-lint-plugin-tailwind uses lib/helpers/create-error-message.

[bmish]

@dcyriller good catch. I don't really like this clunky createErrorMessage function. ESLint definitely doesn't have an equivalent. I'm hoping we can replace this with a future schema API (#1371) or other built-in functionality.

I'm leaning toward not publishing createErrorMessage unless it's heavily used by the plugin ecosystem. If we discover that lots of plugins need it, we can add it to the public API until we have a better alternative.