Add exporting link feature separately

[steffen]

This change allows the link feature to be feature flagged and initialized separately.

[Bestra]

While we're at it could we also export the rest of the install* functions?

Suggested change

	export {subscribe, installLink, uninstallLink}
	export {installLink, installTable, installText, subscribe}

Hmm, if we're installing features separately in the caller, will we also need to make the uninstall* functions available to the caller as well?

[steffen]

While we're at it could we also export the rest of the install* functions?

@Bestra I was not sure if we want to keep this change as a permanent change after we remove the feature flag. If so, then yes, we probably want to export all.

Hmm, if we're installing features separately in the caller, will we also need to make the uninstall* functions available to the caller as well?

Generally I believe we need to export the uninstall* functions as well so that we can call it on remove: https://github.com/github/github/pull/193520/files#diff-56fd9ba9b1627b3f8c4d982bc5106317f74d72fb0cdad47f025ac98d3df042efR14-R23

[Bestra]

I think this is a reasonable permanent change. The extra flexibility doesn't hurt anything, and that'd save us from cutting a new release to remove the functions.

[steffen]

@Bestra One downside that I came to think of during the weekend is that the API for using the paste-markdown library changes with this change as we go from the default export to named exports.
Not sure if there are other users of the library outside of github/github. Either way we probably would want to bump the version to 0.4.x, correct? (not sure if we follow semver, which would be 1.0.x then for a breaking change)

[Bestra]

@Bestra that's a good point! Maybe we could keep the default export as-is and add the named exports in addition to it? That'd avoid breaking any of the existing callers. To that point, though, we'd probably make a second release once this feature is done to add the new feature to the existing subscribe function.

[steffen]

Maybe we could keep the default export as-is and add the named exports in addition to it? That'd avoid breaking any of the existing callers.

@Bestra Great idea! Though, when doing export {subscribe as default, installLink, uninstallLink}, rollup.js outputs this warning when building via npm run build: 😕

(!) Mixing named and default exports
https://rollupjs.org/guide/en/#outputexports
The following entry modules are using named and default exports together:
src/index.ts

Consumers of your bundle will have to use chunk['default'] to access their default export, which may not be what you want. Use `output.exports: 'named'` to disable this warning
created dist/index.esm.js, dist/index.umd.js in 1.6s

By the way, I also tried to to change the imports in wildcard imports to make it easier to pass them to the export, e.g.

import * as table from './paste-markdown-table'
export {subscribe as default, table}

But the eslint rules don't allow that: import/no-namespace

[Bestra]

@steffen 😱 I didn't anticipate this would be a pain. I think bumping the version as you suggested and going to named exports is probably the best course of action. I'd say feel free to move forward as you see fit 👍 . Then we can give this a wholistic look in the context of https://github.com/github/github/pull/193520

[steffen]

@Bestra Perfect! I agree that this seems to be the best route now. Thank you! 🙇‍♂️