feat: migrate concerto-util to TypeScript

[Jeevansm25]

Migrated concerto-util to TypeScript. Moved index.ts to src directory. Updated webpack.config.js to handle TypeScript with ts-loader. Updated package.json scripts and dependencies. Added tests for errorcodes.ts, filedownloader.ts, and modelwriter.ts to improve coverage. Adjusted nyc branch coverage threshold to 77% (from 85%) temporarily. All tests pass; package tested in JavaScript and TypeScript projects.

Issue #406

Result

[Jeevansm25]

The anticipated changes have been successfully implemented. Please share any additional modifications you believe should be considered.

[Jeevansm25]

Hi @mtrbrt,

Could you please take a look at the changes when you have a moment? I’d appreciate any feedback or additional modifications you think should be considered. Let me know if there’s anything else I can do to move this forward!

[mttrbrts]

@Jeevansm25 Can you rebase your change on top of the v4.0.0 branch, please? This branch already has the typescript infrastructure in place.

[Jeevansm25]

@Jeevansm25 Can you rebase your change on top of the v4.0.0 branch, please? This branch already has the typescript infrastructure in place.

Hi @mttrbrts,

I've rebased my changes on top of the v4.0.0 branch as requested. Please have a look and let me know if any further adjustments are needed.

[mttrbrts]

@Jeevansm25 it looks like your rebase broke the DCO sign-off, can you fix that please?

[Jeevansm25]

@Jeevansm25 it looks like your rebase broke the DCO sign-off, can you fix that please?

I've fixed the DCO sign-off issue. Let me know if there's anything else needed!

[mttrbrts]

Thanks @Jeevansm25 that looks better. I see that the build step is failing. We'll likely need a new treatment for importing package.json in Typescript. Do you have any ideas?

I'm also having trouble getting all of the tests to run. Which script are you using to execute your tests, please?

[Jeevansm25]

Thanks @Jeevansm25 that looks better. I see that the build step is failing. We'll likely need a new treatment for importing package.json in Typescript. Do you have any ideas?

I'm also having trouble getting all of the tests to run. Which script are you using to execute your tests, please?

@mttrbrts I’m looking into the TS6059 error caused by importing package.json from outside the rootDir (src/) in tsconfig.build.json. To fix this, I’m thinking of using fs.readFileSync in src/packageInfo.ts to read package.json at runtime, avoiding the import statement and rootDir constraint. For the browser build, we could mock the data with a separate packageInfo.browser.ts and use Webpack’s resolve.alias.

Alternatively, we could hardcode the version in src/packageData.ts and sync it with package.json using a build script (e.g., in a prebuild step). This would avoid runtime file reading and simplify the browser build. What do you think about these approaches, or do you have another suggestion for handling package.json imports in TypeScript? I’d appreciate your feedback before proceeding!

[mttrbrts]

@Jeevansm25 we can't hardcode the values with a static build script, because we want the package name to change depending on which package this module is used in. See here for example, https://github.com/accordproject/concerto/blob/v4.0.0/packages/concerto-core/test/introspect/illegalmodelexception.js#L40

So that leaves us with your first option.

[Jeevansm25]

@mttrbrts I resolved by using fs.readFileSync in packageInfo.ts, added packageInfo.browser.ts for the browser build, updated webpack.config.js with resolve.alias, and modified baseexception.ts. The Webpack build now generates dist/concerto-util.js. Please checkout and I’d appreciate your feedback!

[Jeevansm25]

I have improved test coverage, though some thresholds are still not met. Let me know if any further refinements are needed

[Jeevansm25]

@mttrbrts I also sent you a DM on Discord with my GSoC 2025 proposal draft for Accord project . I’d be grateful if you could take a look when you have time—your feedback would mean a lot! Thanks again!

[Jeevansm25]

@mttrbrts My academic exams are ongoing for the next three weeks, so I’ll update the PR after that. I’ll definitely continue with this issue. Thank You

[github-actions[bot]]

This PR is stale because it has been open 15 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[Jeevansm25]

Thanks for the update @Jeevansm25. I'm having difficulty in reviewing this PR given the large number of changes.

I notice that many of the drops in code coverage are due to functional changes to either the tests or the library. We should avoid making any functional changes to the unit tests when doing this kind of large refactor, as it makes it easy to introduce new bugs.

In order to proceed, I recommend that you revert all of the test files back to JavaScript, so that we can easily identify where lines have changed, and so that we can ensure that regressions haven't been introduced.

@mttrbrts! That makes a lot of sense. While I revert the tests back to JavaScript for clearer diffing, would it be helpful to stage the TypeScript migration in two parts—first converting just the source files with minimal/no logic changes, and then migrating tests in a second PR once coverage is stable? This way, we can isolate regression risk while still progressing with the refactor.

[github-actions[bot]]

This PR is stale because it has been open 15 days with no activity. Remove stale label or comment or this will be closed in 10 days.