Packaging updates

[asimgunes]

Hi @jonahgraham,

I like to discuss this update as a follow-up changes for previous work at pull-request #96.

In this update:

• Removed the "CLI development" option from build scripts, and minify and extract source map at all times.
• Removed the tsc compiler execution at build phase, leave build operation to ESBuild. Thus remove out folder extract all the output at dist folder.
• Optimised the build scripts and include ESModule format besides to CommonJS format.
• Added types decleration to build output.
• Set the CJS, ESM entry points and types decleration entry points in package.json
• Minor changes at VSIX package files (at .vscodeignore).
• Minor changes at Node package files (at package.json).

Benefits:

• Included source map files at all times, ease the debug operation.
• Included type declarations made cdt-gdb-vscode easy to use as a package depedency.
• Removing tsc at the build phase do not have any side effect (as far as I observed). Besides remove the redundant/unnecessary out folder from the build output (Since entry points already changed to dist folder.)

I didnot add any script definition for triggering package publishing operation in npm registry, but, after this update, I believe we can publish cdt-gdb-vscode as an npm package and anyone could easily use cdt-gdb-vscode as a dependent package and extend behaviour.

I hope this would create a positive impact for cdt-gdb-vscode.

Kind regards. Asim

[eclipse-cdt-bot]

Can one of the admins verify this patch?

[colin-grant-work]

This style of export also doesn't play very nicely with the TypeScript language server. In a dependent, I can write an import for the MemoryServer in three ways, all of which the TS server is happy with:

import { MemoryServer } from 'cdt-gdb-vscode'; // Will work

import { MemoryServer } from 'cdt-gdb-vscode/dist/extension'; // Will work

import { MemoryServer } from 'cdt-gdb-vscode/dist/memory/server/MemoryServer'; // Won't work

The problem is that, when the code is bundled, the generated .d.ts files don't actually correspond to files present on disk, but the TS server assumes that .d.ts files should be in a 1:1 correspondence with transpiled .js files. With this setup, it would be more correct to concatenate the content of all of the .d.ts files into extension.d.ts, since that's the only .js file actually available. Perhaps it would be best to run three builds:

• bundled into extension.js for consumption as a plugin
• unbundled into .esm.js files for consumption as ES Modules
• unbundled into .cjs.js file for consumption as Common JS modules

with one of the last two including the .d.ts file generation.

[jonahgraham]

@asimgunes please see conversation in #112 also.

[asimgunes]

Hi @jonahgraham, @colin-grant-work,

I rebased the request and keep minimum by only adding required type declerations and minor changes in esbuild code, since @colin-grant-work rollback previous changes.

Could you please review the changes again?

[colin-grant-work]

I'll take a look today