expose version variable from @sveltejs/kit

[ivanhofer]

Describe the problem

inlang creates an i18n solution that integrates well into any SvelteKit application. We set things up in an automated way, so we need to know which features are available in the current installed version of SvelteKit.
e.g. the entries feature was recently introduced and we want to use it, but we can't really tell if it is supported becasue we don't know the installed version of SvelteKit on a developer's machine. If we would just add it, SvelteKit would throw an error.

We currently use npm list --depth=0 @sveltejs/kit to read the information, but it is not really reliable.
Therefore it would be great if SvelteKit would expose the version info.

Describe the proposed solution

expose a version prop that can be read by any application.

import { version } from '@sveltejs/kit'
console.log(version)

Details

Probably the easiest solution would be to create a file /src/version.js

export const version = '1.16.3'

and expose it in /src/exports.js

export { version } from '../version.js' 
// ...

A script in CI (release.yml) would override the /src/version.js file with the actual version property from package.json.

Note: we can't just read and export the property from package.json because SvelteKit does not have a build-step and importing json files is curently not well supported in native Node.js.

Alternatives considered

None

Importance

would make my life easier

Additional Information

If this is something the SvelteKit team considers, I can create a PR in the coming days.

[Conduitry]

The @sveltejs/kit exports map already includes ./package.json, so you should be able to just:

import pkg from '@sveltejs/kit/package.json' assert { type: 'json' };
console.log(pkg.version);

[ivanhofer]

I was also thinking about that first. But Import assertions are still experimental: https://nodejs.org/api/esm.html#import-assertions
If we would use that every user would be greeted with this error message on each application start:

(node:26218) ExperimentalWarning: Import assertions are not a stable feature of the JavaScript language. Avoid relying on their current behavior and syntax as those might change in a future version of Node.js.
(Use `node --trace-warnings ...` to show where the warning was created)
(node:26218) ExperimentalWarning: Importing JSON modules is an experimental feature and might change at any time

Import assertions were backported to Node 16.14 which is the minimum supported Node version for SvelteKit. So it should work. But I'm not sure if it is the best way to do this given the experimental state.

[tcc-sejohnson]

Given that we can achieve this with an experimental feature, I'd prefer not to add the feature to Kit -- if, in the future, the experimental feature is dropped or we can't use it for some reason, then we could circle back to this. The warning is annoying -- is there any way we could suppress it?

[Rich-Harris]

Import assertions don't currently work inside .svelte files — presumably we need to update acorn or something somewhere. We could fix that, but this feature would still be restricted to users of a future version (which realistically at this point means the next major).

The @sveltejs/kit exports map already includes ./package.json

I forget why we did that, but I'm not sure it's a good practice. (IIRC some Svelte bundler plugins used it at one point to determine if a given package was a Svelte library or not, but that caused problems and is no longer the case.) I don't think it's a widespread habit, and to be honest I'd be in favour of removing it from the exports map in v2.

So for those two reasons, combined with the two ExperimentalWarning messages, I don't think we should encourage people to use it that way. I don't think I'd be opposed to this addition, though I would favour VERSION over version to distinguish it from version in $app/environment.

[Conduitry]

That's fair. It would be nice if we could get this to work somehow other than adding more moving parts to automatically update this file, but I'm not sure that would be possible, given the unbundled nature of the package.

[ivanhofer]

I have created a PR: #9969