Way to keep sdk5 and 4 branches in sync?

[3v1n0]

There are some differences in the UI, but the backend can stay the same...

So not sure if we can use a git submodule, or probably we can even share the whole codebase, but use two different uiManager and stylesheet files.

The only problem that would happen is having a way to dynamically set the buildTargets, and not sure how we can do it.

[Artaud]

I'm thinking we could scratch using branches and have it all in one branch. Packages could be built conditionally, based on the build targets in package.json. I'm already doing something similar with version (to see version from package.json at runtime), using "prebuild" npm hook:

SleepAsFitbit/package.json

Line 33 in 2001187

"prebuild": "cat package.json | echo 'export const version =' $(jq '.fitbit.version') > ./version.ts"

We could have an npm script, something like build-all-targets, which would replace the buildTargets in package.json, then make the buildTargets visible for the app, which could load modules (like UiManager) conditionally based on buildTargets. It will then call build, then again replace buildTargets for the second SDK version and build again. We'd probably need to also rename the resulting package so as not to overwrite it by the second build.

This would probably prevent treeshaking of the unused modules (?) but I think we're talking a few kBs max. I'm not sure how the build tool handles when there's both widgets.gui & widget.defs, index.gui & index.view in the project at the same time but I guess it could be okay.

[Artaud]

We will need to define an interface however for the modules that will be different for different SDK levels.

[3v1n0]

Yeah, I'm not a huge expert of the npm and package.json world, so I was imagining something like a pre-hook that does the thing.

What I'm not sure how to handle is the fact that the package.json should contain different supported models, that should be instead a template.

Could the package.json use an .in file instead that is generated when we do npm build and make sure that this also works when using build from npx fitbit shell?

[Artaud]

I'm not familiar with .in files, could you give me a hint? But templating the buildTargets in seems like a good idea.

I'm not sure whether it could work from the npx fitbit shell as in any case, we need to build twice. We could hack into it using the prebuild hook, which in turn maybe could call build again, but that seems a little convoluted to me.

[3v1n0]

I mean a package.json.in file with some templates that generates a package.json... It's something coming from the autotools ideas for generating Makefile's, but not sure it applies here :)

[Artaud]

Understand. Simple to do with some bash-fu.

[Artaud]

Damn, this wouldn't work - we'd need to have @fitbit/sdk in two versions at the same time, which I don't think is possible. I don't think we can build a v4 app with SDKv5

[Artaud]

I just had a stream of consciousness at the fitbit discord, copying it here for reference as I think the build could be done this way:

artaudToday at 11:26
Yep right...I was trying to think up a way to build both sdk4 and sdk5 version of my app in one command
hexxehToday at 11:28
You'd have to do some kind of script to swap the file content in and out
The other thing I've considered is letting you specify buildTargets on the command line
Partly for slightly faster iterative builds, but also useful here
That way you can yarn-install two different SDK versions at once and flip between them
artaudToday at 11:31
That would be super useful. But I think I can do with swapping the package.json contents.
Actually, that could be a generic utility. The only hassle is that you'd need to manage your dependencies by hand and could not use yarn/npm when adding or updating a lib.
But that's probably not going to be much of an issue, considering that Fitbit apps are very small projects.
And even that could be remedied. Something like fitbit-swap load 4 will load your package.4.json into package.json. Now you can manage it with npm/yarn. Then fitbit-swap save 4 will save your current package.json into package.4.json
And of course, fitbit-swap build will build your apps using package.4.json and then package.5.json
There are also issues with managing other fields than just buildTargets and dependencies. So the version json files will probably just consists of deps and buildTargets. Then it could work.

[3v1n0]

Yeah, not really much different from having a build system that prepares the files first, but that seems something useful to have indeed :)