Like ember-cli/babel-plugin-ember-modules-api-polyfill#38 and ember-cli/babel-plugin-ember-modules-api-polyfill#39, import '@glimmer/env'; suffers the same problem and should be removed. It should also be fixed on the 0.1.x series.

Started getting this error recently on my project, just when running ember s though others don't get it. Any ideas?

The Broccoli Plugin: [Funnel] failed with:
Error: ember-data/-debug/index.js: You must specify envFlags.flags.DEBUG at minimum.
  at normalizeOptions (<redacted>/node_modules/babel-plugin-debug-macros/dist/lib/utils/normalize-options.js:74:11)
  at PluginPass.enter (<redacted>/node_modules/babel-plugin-debug-macros/dist/index.js:33:60)

Ember 3.27+ emits a deprecation when accessing window.Ember. At the moment, our transpilation output emits:

Instead, we should use the import that the original code used.

Thoughts?

Introduce a "externalHelpers" API that allows for mocking out macros for things like testing.

Given the following config:

    [debugMacros, {
      envFlags: {
        source: '@glimmer/env-flags',
        flags: envFlags
      },
      debugTools: {
        source: '@glimmer/debug'
      },
      externalizeHelpers: {
        module: true
      }
    }],

And the following module contents (note no imports):

var DEBUG = 'hahaha';

if (DEBUG === 'hahaha') {
  // do things
}

The DEBUG assignment is removed, and the usage is changed to boolean:

if (false === 'hahaha') {
  // do things
}

This is getting pretty unwieldy. Should be broken up into the following:

['debug-macros', {
   debug: boolean,
   source: string,
   externalizeHelpers: { module: true, global: string }
],
['feature-flags', { debug: boolean, flags: Object, source: string }]
['svelte', { flags: Object, debug: boolean, source: string }]

Likely need to check if there are other options that each plugin needs.

Take for instance the following

assert(`my assertion`, SOME_VAR);

This library will close over SOME_VAR when building out the transformation _createMacroExpression. Since the built transformations are not flushed until program exit, other transforms that edit or replace SOME_VAR will have no affect.

Investigate creating a contract for consumers to explicitly strip deprecations within a specific semver range.

Currently, given:

import { SOME_FLAG } from 'blah/features';

if (SOME_FLAG) {
  console.log('whatever');
}

With this config:

{
  plugins: [
    ['babel-debug-macros', {
      features: {
        name: 'blah',
        source: 'blah/features',
        flags: { SOME_FLAG: true }
      },
    }]
  ]
}

We remove the usage of SOME_FLAG, but leave the import statement. This forces us to also emit a blah/features module even if we never have runtime enableable features.

IMO, we should remove imports if they are no longer used...

I have this code:

assert('Need profile data', this.args.window.profile?.data);

When optional chaining is not transpiled, things work fine. The line above is transformed to:

(true && !(this.args.window.profile?.data) && (0, _debug.assert)('Need profile data', this.args.window.profile?.data));

However some automated dependency updates including most Babel stuff changed behavior, in that optional chaining is now transpiled, I believe due to some bug in Chrome, see babel/babel#13145.

But now the transform yields this broken code:

var _this$args$window$pro;

(true && !(_this$args$window$pro.data) && (0, _debug.assert)('Need profile data', (_this$args$window$pro = this.args.window.profile) === null || _this$args$window$pro === void 0 ? void 0 : _this$args$window$pro.data));

Which throws with Cannot read properties of undefined (reading 'data') as at the time the !(_this$args$window$pro.data) expression is evaluated _this$args$window$pro is still undefined!

Maybe this already exists, but didn't see the functionality while skimming the source:

usage:

• https://github.com/emberjs/ember.js/blob/ee8ab348484421f254fe995c6f04f0d4a0859cfa/packages/ember-debug/lib/index.js#L134-L157
• https://github.com/emberjs/data/blob/master/addon/-private/debug.js#L19-L21

Currently, we are handling only ExpressionStatement's for debug macro replacement. Unfortunately, the following do not get processed (since they do not include an ExpressionStatement):

function foo() {
  return assert(false, 'derp'); // ReturnStatement
}

let qux = () => assert(false, 'herp'); // ArrowFunctionExpression

This is the underlying issue in emberjs/ember-cli-babel#168.

The current system does not work for the following statements:

if (SOME_FLAG && whatever && whatever) { }

if (!SOME_FLAG) {}

let something = SOME_FLAG ? one : two;

Given this reproduction file: https://github.com/simonihmig/ember-warn-transpilation/blob/master/app/utils/warn.js

This is transpiled to:

define('ember-warn-transpilation/utils/warn', ['exports'], function (exports) {
  'use strict';

  Object.defineProperty(exports, "__esModule", {
    value: true
  });
  exports.default = warn;
  function warn() {
    (true && Ember.emberWarn(...arguments));
  }
});

Where Ember.emberWarn is obviously not a thing.

warn(...arguments);

is apparently being transpiled to

 (false && _ember.default.warn(...arguments));

but ...arguments is ES6 code, which ember-cli-uglify@1 is not able to handle.

see mainmatter/ember-simple-auth#1443

/cc @rwjblue

• Add Node 4 to CI.
• Add additional babel plugins (or swap to babel-preset-env) to support node 4.

This should not throw (though Ember will issue a deprecation for not passing the options hash):

import { deprecate } from '@ember/debug';

deprecate('some message');

Currently the following (lovely) error is thrown:

TypeError: -private/system/store.js: Property expression of ParenthesizedExpression expected node to be of a type ["Expression"] but instead got null
    at Object.validate (/Users/rjackson/src/open-source/ember-data/node_modules/babel-types/lib/definitions/index.js:109:13)
    at validate (/Users/rjackson/src/open-source/ember-data/node_modules/babel-types/lib/index.js:505:9)
    at Object.builder (/Users/rjackson/src/open-source/ember-data/node_modules/babel-types/lib/index.js:466:7)
    at Builder.deprecate (/Users/rjackson/src/open-source/ember-data/node_modules/babel-plugin-debug-macros/dist/lib/utils/builder.js:187:92)
    at Macros.build (/Users/rjackson/src/open-source/ember-data/node_modules/babel-plugin-debug-macros/dist/lib/utils/macros.js:189:36)
    at PluginPass.ExpressionStatement (/Users/rjackson/src/open-source/ember-data/node_modules/babel-plugin-debug-macros/dist/index.js:67:27)
    at newFn (/Users/rjackson/src/open-source/ember-data/node_modules/babel-traverse/lib/visitors.js:276:21)
    at NodePath._call (/Users/rjackson/src/open-source/ember-data/node_modules/babel-traverse/lib/path/context.js:76:18)
    at NodePath.call (/Users/rjackson/src/open-source/ember-data/node_modules/babel-traverse/lib/path/context.js:48:17)
    at NodePath.visit (/Users/rjackson/src/open-source/ember-data/node_modules/babel-traverse/lib/path/context.js:105:12)

We should basically do the same as we do for deprecate in this regard.

Today, this input:

import { deprecate, assert } from 'whatever';

deprecate('foo bar', somePredicate, { ... });
assert(somePredicate, 'message here');

Transpiles to:

(true && !(somePredicate) && console.warn('foo bar'));
(true && console.assert(somePredicate, 'message here'));

Note that the deprecate version avoids allocating the string if the predicate is truthy, but the assert version does not.

We currently have 4 or 5 assertions for every get / set (for example), and it would be nice to make assert a bit less expensive in debug builds of Ember...

Investigate if we can DCE early with path.execute in Babel.