Closed NullVoxPopuli closed 2 years ago
if I revert back to Ember 4.0.1
the error goes away, so this seems to be an issue with dependencySatisfies
?
I confirm the fix by changing the macroCondition to just true
in node_modules. but I am unable to get 4.1.0-beta or 4.2.0-alpha to match the dependencySatisfies
I tried adding >= 4.0.0
to the dependencySatisfies condition, but:
still false.
I don't think it's an issue with the SemVer version range itself. includePrerelease
is set so it should also match the prerelease versions.
Can you debug the dependencySatisfies
macro to see from where it returns false
?
adding console.logs in node_modules seems to not show anything :shrug:
ah ha! https://github.com/embroider-build/embroider/blob/1f400720511644b78d5dc4e336f3a7c7a18d312b/packages/macros/src/babel/dependency-satisfies.ts#L39 I'm falling in to this branch --
unable to resolve package ember-source from /tmp/embroider/66dd2e/node_modules/@embroider/util
unable to resolve package ember-source from /tmp/embroider/66dd2e/node_modules/ember-focus-trap
(but multiple times)
at PackageCache.resolve (/✂️/limber/node_modules/@embroider/shared-internals/src/package-cache.js:29:21)
at dependencySatisfies (/✂️/limber/node_modules/@embroider/macros/src/babel/dependency-satisfies.js:40:36)
at Evaluator.evaluateMacroCall (/✂️/limber/node_modules/@embroider/macros/src/babel/evaluate-json.js:319:81)
at PluginPass.enter (/✂️/limber/node_modules/@embroider/macros/src/babel/macros-babel-plugin.js:127:71)
at newFn (/✂️/limber/node_modules/@babel/traverse/lib/visitors.js:177:21)
at NodePath._call (/✂️/limber/node_modules/@babel/traverse/lib/path/context.js:53:20)
at NodePath.call (/✂️/limber/node_modules/@babel/traverse/lib/path/context.js:40:17)
at NodePath.visit (/✂️/limber/node_modules/@babel/traverse/lib/path/context.js:100:31)
at TraversalContext.visitQueue (/✂️/limber/node_modules/@babel/traverse/lib/context.js:103:16)
@ef4 would it make sense to fall back to the app's ember-source
if we get in to this branch?
In older APIs that we're trying not to break we allow that kind of fallback. But this is new API and we're trying to be strict.
Instead we should list ember-source as a peerDep of @embroider/util
, so that it's always resolvable regardless of hoisting / monorepos / alternative package managers.
Here is my work-around for now:
// @ts-check
'use strict';
const path = require('path');
const fs = require('fs/promises');
const modules = path.join(__dirname, 'node_modules');
/**
* These are patches to packages where things work for
* this project, but I don't yet know what the proper way to fix the issue
* for real is.
*/
async function start() {
await patchEmbroiderIssue1038();
}
async function patchEmbroiderIssue1038() {
console.log('Patching @embroider/util due to https://github.com/embroider-build/embroider/issues/1038');
let emberPrivateApi = path.join(modules, '@embroider/util/addon/ember-private-api.js');
let fileBuffer = await fs.readFile(emberPrivateApi);
let file = fileBuffer.toString();
// the macro-condition for this file doesn't work because embroider can't find
// ember-source.
// since we know that
file = file.replace(/macroCondition\(/, 'true || (');
await fs.writeFile(emberPrivateApi, file);
}
start();
and then in package.json:
"scripts": {
"prepare": "node patch-packages.js",
This is a preliminary issue, but cropped up -- not sure why yet.
There is only one occurrence of
window.Ember
: which comes from: which is defined here: https://github.com/embroider-build/embroider/blob/fb866769e53b3ce543ce85ab3640be5be10239be/packages/util/addon/ember-private-api.js#L9-L19Here is the code / error:
and related error: