and adjust package.json so that types are picked up in consumer projects

Summary

The code base is still plain JS as before (the build did not change) but this now allows outputting declaration files so that consumers that can start to import Docsify via ES Modules with type definitions.

Related issue, if any:

• Simplify and modernize Docsify #2376

What kind of change does this PR introduce?

Feature (dev experience)
Build-related changes (adds a build step that outputs declaration files, but otherwise does not change the build in any other way)

For any code change,

• Related documentation has been updated, if needed
• Related tests have been added or updated, if needed

Does this PR introduce a breaking change?

No

Tested in the following browsers:

• Chrome
• Firefox
• Safari
• Edge

Additional info

Several changes:

• Improved types within Docsify source code
  • Improves many type definitions inside Docsify source code for our own sake, but many things are still inferred as type any and can be fixed later.
  • The noImplicitAny option is set to false in tsconfig.json to disable ~600 type errors that will otherwise happen.
• Type support for consumers
  • This outputs types declaration files (files ending with .d.ts) alongside files in src/. We do not output types to dist/ because that conflicts with the folder structure there. The dist/ folder is only for the global build, and we may optionally place bundled ESM builds there later, but otherwise ESM imports are directly from src/ and the sibling output .d.ts files automatically provide type awareness for consuming TypeScript projects.
  • The src/ folder is now added to the files array in package.json.
  • The added tsconfig.json sets up TypeScript rules.
  • The new build:types scripts causes .d.ts and .d.ts.map files to be emitted next to .js files in src/. This step does not do anything with the .js files, those are handled in the pre-existing build separately.
    • The .d.ts files provide declarations for consumption, and the .d.ts.map files allow features like Go To Definition on Docsify APIs to take someone directly to the source definition in their IDEs.
  • There is a new test in test/consume-types which is a sample project that imports Docsify to bootstrap a Docsify site (see those files for more details).
    • We're not e2e testing the result of this sample project, but maybe we should. I verified the example manually.
    • This sample project does not have a build, it is vanilla ESM that runs in browser, witha few hacks for importing prismjs (which is in CommonJS format) and common-tags (which has bespoke import specifiers pointing to folders instead of JS files).
    • We can, and maybe should, make other sample projects later than use some common build tools to build Docsify into an app bundle, to verify imports are working well in JS ecosystem tooling.
  • The new test:consume-types script goes into test/consume-types directory, installs Docsify and Docsify's dependencies into its local node_modules, and runs type checking with TypeScript to verify the types are imported as expected via ESM.
    • This script is added to our CI.
• new Docsify(config) API
  • Global APIs are against the grain of ESM code where globals are generally avoided, and working with global types with TypeScript in consumer projects would be a lot less ideal. So for people importing Docsify, they can now pass options directly to the Docsify constructor, while getting type checking and intellisense on all the available options:

    import {Docsify} from 'docsify'
    
    new Docsify({
      el: '#app',
      name: true,
      // ...etc...
    })

  • This is not the new Custom Element API we're planning, but is a middle ground so we can release something non-breaking in 5.0, which is already in release candidate.
    • We might be able to release a Custom Element API in 5.0 non-breaking, but if anything we can release that in 6.0.