Relates #1111
Given that we will be re-using the migration script for kit@3 we want to overhaul it beforehand. The current setup is mainly regex-based and mostly uses magic-string to do replacements. This has proven to be error prone.
Based on the setup we build for sv and sv-utils we can do better. We should be re-using all of the well proven and tested ast utils we have accumulated over time. and for printing we will use sveltes new print functionality and esrap for non svelte files.
Based on the learnings from the previous migrations, the following things should be possible:
- migrete files or subdirs one by one (flexible cmd args)
- allow selecting different migrations to run
- allow more flexibility in what the migration executes (you might not want to move all features immediately to seperate commits and stuff like that)
The code could look something like this, but this only a really early, un-tested and un-proven idea.
WIP, very early idea
export default defineMigration({
id: 'kit-3',
changelog: 'https://svelte.dev/blog/whatever'
run: () => {
// ask the users more questions if required
return {
pkg: ...pkgTask,
config: ...moveConfigToViteTask,
env: ...coolNewEnvTask
}
}
});
function pkgTask({sv, files}) {
// ask more questions for the migration task
return defineMigrationTask({
name: 'Update package.json',
isRequired: true,
isApplied: () => {
const isApplied = false;
sv.file(
files.match('package.json'),
transform.json({data} => {
const version = getDependencyVersion(data, '@sveltejs/kit');
isApplied = version && semver.gte(version, '3.0.0'); // pseudo
// no return, so not modifying the file
})
)
},
run: () => {
sv.file(
files.match('package.json'),
transform.json({data} => {
data.dependencies['@sveltejs/kit'] = '^3.0.0';
return data;
})
)
}
})
}
Relates #1111
Given that we will be re-using the migration script for kit@3 we want to overhaul it beforehand. The current setup is mainly regex-based and mostly uses
magic-stringto do replacements. This has proven to be error prone.Based on the setup we build for
svandsv-utilswe can do better. We should be re-using all of the well proven and tested ast utils we have accumulated over time. and for printing we will use sveltes newprintfunctionality andesrapfor non svelte files.Based on the learnings from the previous migrations, the following things should be possible:
The code could look something like this, but this only a really early, un-tested and un-proven idea.
WIP, very early idea