Open unional opened 8 years ago
So, updates are easy enough. The hard part is deciding what constitutes an update. I'm tempted to push toward the easy solution, which is the new scheme we've described as the install command. E.g. npm!domready
. When it lands in typings.json
, we append the tag we installed at: npm!domready#1.0.8+20160211010015
(which I've already made the relevant changes to the API to handle this today). Now, we just add support for resolving that scheme to the registry first, source second, when installing. My only reservation on this is registry uptime - right now I've had about 10 minutes down time in the last week but that doesn't block builds, changing this will.
The other options are (1) creating a lookup entry that basically reverses the installation source and then does what's described above or (2) doing a resolution using the relevant APIs for updates (E.g. ask GitHub for later commits. 2 is tough and a lot of work, 1 is nicer but could be confusing. I still prefer option 0 above, but that's my thoughts right now.
Edit: All this ignore semver ranges right now. Opted to defer that for later. If ranges ever are used, the registry scheme will likely change to match.
(1) sounds familiar. I think jspm
did something similar. Need citation. :smile:
btw, just for reference (as it might help in this context). jspm
differs from npm
in the following:
// package.json
{
"jspm": {
"dependencies": {
"bluebird": "npm:bluebird@^3.1.1" // distribution-channel, package name, and semver range
}
}
}
// jspm.config.js
{
map: {
"bluebird": "npm:bluebird@3.1.1", // mapping
"npm:bluebird@3.1.1": { // dependency
"process": "github:jspm/nodelibs-process@0.1.2" // mapping of dependency
},
"github:jspm/nodelibs-process@0.1.2": { // dependency
"process": "npm:process@0.11.2" // mapping of dependency
},
}
}
# folder structure
+ jspm_packages
+ npm
+ bluebird@3.1.1
+ ... package content
+ bluebird@3.1.1.js // redirection file
// jspm_packages/npm/bluebird@3.1.1.js
// Path is based on the `main` field in `bluebird/package.json`
module.exports = require("npm:bluebird@3.1.1/js/browser/bluebird.js");
Yes, I think I've been stealing the API look from JSPM and tweaking to fit Typings needs - which change slightly as we want highly specific versions and have two "schemes" concurrently (well, the registry could actually be it's own scheme). However, they don't actually need to do the reversal or updates at all, since they're supported by the target consumption sources (E.g. NPM/GitHub) and they are 1-to-1. Typings isn't 1-to-1 with the sources (maybe that's a mistake, can't know yet still).
So the final thing around installation/update is the official syntax. We could expand npm!domready
into registry:npm/domready#1.0.8+20160211010015
, which registry:
is now just another scheme to resolve over - I feel like having that doesn't give any advantage though. Thoughts on how the registry is persisted?
Spawn from https://github.com/typings/core/issues/8#issuecomment-191445946
Objective
Variables
Scenario 1: current
npm:domready@a.b.c
"a.b.c": "http://...#SHA1"
typed-domready@SHA1
// Can't help to use nametyped-domready
instead ofnpm-domready
:smirk:npm:domready@p.q.r
"p.q.r": "http://...#SHA2"
typed-domready@SHA2
Scenario 2: with semver range + typings/registry
npm:domready@a.b.c
npm/domready.json
// TODO: Need better example than A-Da. Read versions in reverse order, assuming later version is newer. b. Get and use first matched version
Known problems to solve