This would have to be tackled one repo at a time. I started here. I have a PR for this in the works.

See aurelia/framework#294

typings install -S github:aurelia/pal

🌷

I'm submitting a bug report
I'm submitting a feature request

• Library Version:
  major.minor.patch-pre

Please tell us about your environment:

• Operating System:
  OSX 10.x|Linux (distro)|Windows [7|8|8.1|10]

• Node Version:
  6.2.0

• NPM Version:
  3.8.9

• JSPM OR Webpack AND Version
  JSPM 0.16.32 | webpack 2.1.0-beta.17

• Browser:
  all | Chrome XX | Firefox XX | Edge XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView

• Language:
  all | TypeScript X.X | ESNext

Current behavior:

Expected/desired behavior:

• What is the expected behavior?

• What is the motivation / use case for changing the behavior?

Hello,

Apologises for not following the template. It seemed a bit extreme for what the issue ultimately is.

"dist/types/aurelia-metadata.d.ts"

"dist/types/" directory is currently not on master and as such builds referencing the master branch are failing when they can not retrieve typings.json.

As a workaround and to assist anyone else with the same issue, we are now explicitly targeting 1.0.7 in our typings.json

"aurelia-metadata": "github:aurelia/metadata#1.0.7",

Thanks

Hello, I ran into this issue when using aurelia-validation's validationRenderer decorator.

I'm submitting a bug report

I would expect the decorator returned by the protocol function to return the passed target.

Library Version:
1.0.0-rc.1.0.1
Please tell us about your environment:
Not relevant

Current behavior:
protocol decorator returns undefined

Expected/desired behavior:
protocol decorator should return the target or the resolved target so that other decorators can be used. My use case is to use the transient decorator. Put it before and undefined is passed, put it after and validationRenderer cannot find the render and unrender methods/

Suggested solutions

1/ A wisely located return target; here would fix the issue.

2/ If, for some reason, the function returned by protocol should not return anything, then it can be fixed in protocol.create here, using:

  let result = function(target) {
    let decorator = protocol(name, options);
    if (target) {
      decorator(target);
      return target;
    }
    return decorator;
  };

Hi there,

When installing the TypeScript typings for a project that uses aurelia-metadata with typings install you will see the following output:

typings WARN badlocation "github:aurelia/pal" is mutable and may change, consider specifying a commit hash
├─┬ aurelia-metadata
│ └── aurelia-pal

This happens because https://github.com/aurelia/metadata/blob/master/typings.json does not specifies a version. Wouldn't it be better if the aurelia-pal dependency was specified as e.g.
"aurelia-pal": "github:aurelia/pal#1.0.0"
instead of just
"aurelia-pal": "github:aurelia/pal".
That would resolve the imho justified warning.

PS: The same applies to https://github.com/aurelia/pal-browser/blob/master/typings.json.

I'm submitting a bug report

• Library Version:
  1.0.3

Please tell us about your environment:

• Operating System:
  Windows 10

• Node Version:
  7.3.0

• NPM Version:
  3.10.10

• JSPM OR Webpack AND Version
  JSPM 0.16.32

• Browser:
  Chrome

• Language:
  Typescript 2.1.x

Current behavior:

Using the aurelia-dependency-injection with nodejs fails if aurelia-polyfills is not included. Could this be an import for aurelia-metadata?

Expected/desired behavior:

would like to not have to import 'aurelia-polyfills' every time I use Aurelia dependency injection in NodeJS.

• What is the expected behavior?

import 'aurelia-polyfills' not needed

• What is the motivation / use case for changing the behavior?

To make work properly in NodeJS

Suddenly got the following exception;

D:\Code\aurelia-template-lint\node_modules\aurelia-metadata\dist\commonjs\aureli
a-metadata.js:34
return Reflect.getOwnMetadata(metadataKey, target, targetKey);
^
TypeError: Reflect.getOwnMetadata is not a function
at Object.getOwn (D:\Code\aurelia-template-lint\node_modules\aurelia-metadat
a\dist\commonjs\aurelia-metadata.js:34:20)
at Object.get (D:\Code\aurelia-template-lint\node_modules\aurelia-metadata\d
ist\commonjs\aurelia-metadata.js:27:27)
at Container.autoRegister (D:\Code\aurelia-template-lint\node_modules\aureli
a-dependency-injection\dist\commonjs\aurelia-dependency-injection.js:465:53)
at Container.get (D:\Code\aurelia-template-lint\node_modules\aurelia-depende
ncy-injection\dist\commonjs\aurelia-dependency-injection.js:519:21)
at SyntaxRule.ASTBuilder (D:\Code\aurelia-template-lint\dist\ast.js:10:41)
at SyntaxRule (D:\Code\aurelia-template-lint\dist\rules\syntax.js:10:9)
at new AureliaLinter (D:\Code\aurelia-template-lint\dist\aurelia-linter.js:3
5:13)
at Object. (D:\Code\aurelia-template-lint\example.js:11:14)
at Module._compile (module.js:541:32)
at Object.Module._extensions..js (module.js:550:10)

What is rather troubling is that this has happened out of the blue and still happens after locking evertyhing to 1.0.0-rc.1.0.0

aurelia-validation 0.6.2 unit tests are passing (once missing dependent libs are installed) when using aurelia-metadata 1.1.3.

updating aurelia-metadata to 1.1.4 causes the library's ensure decorator to stop working altogether. see aurelia/validation#216

$jspm install aurelia-metadata
... Installed aurelia-metadata as npm:aurelia-metadata@^1.0.0-beta.1.1.4 (1.0.0-beta.1.1.4)
... aurelia-metadata 1.0.0-beta.1.1.3 -> 1.0.0-beta.1.1.4

Unit tests in aurelia-validation will now fail - as the ensure decorator no longer functions.

Not seeing any commits in this package of note from 1.1.3 to 1.1.4. What could be causing this inter-dependency failure?

I am spinning off the discussion with @niieani that started in this comment because it deserves a thread of its own.

Context

Aurelia uses some conventions based on module names. For example if a ViewModel doesn't explicitly indicate a view, Aurelia will assume the view is found inside a sibling module with extension .html.

This relies on the knowledge of which module a ViewModel came from. For everything loaded by aurelia-loader, this is easy because the loader tags the classes with the request they originated from.

If the ViewModel was statically imported (i.e. not through aurelia-loader), then things get far more tricky. This situation is unusual but possible, e.g. aurelia-dialog supports that.

Current Strategy

When asked for the origin of a ViewModel that wasn't tagged, aurelia-metadata currently does this:

1. Every loaded module is iterated;
2. Each exported value is compared to the ViewModel;
3. If they match the module id is attached to the ViewModel.

Problems

The strategy is not very efficient, but that's a rare, one-time thing, so that's probably OK.
More problematic are the assumptions of steps 1. and 3.

• It is not a given that we may enumerate all loaded modules and/or get their id.
  In fact, according to @niieani we don't support that for SystemJS, NodeJS doesn't support it either and AFAIK it won't be possible with native ES import.
• Even when we can, that strategy is fragile. If a class is re-exported in another module then our logic breaks (this is not totally uncommon with the barrel "reexport everything" JS pattern).
• The new trend is scope hoisting. Rollup does it and Webpack is looking into adding support. The idea is that static dependencies can all be merged in a single scope and totally forget about modules anyway. This can result in smaller bundles, that load faster.

Solutions?

Given the above I'm really not sure what's the way forward.

As far as webpack is concerned:

• Preserving the module id of the ViewModel would be sufficient to make it work, because webpack supports 1 and 3 (at least for now). As noted, this won't be true for all platforms.
• We could enhance code at build time to add calls to Origin.set(). A non-webpack build would need its own automatic (or manual) solution.

In both cases, determining when this is necessary is up for discussion.

@EisenbergEffect Thoughts?

Since Angular 2.0 is dropping the development of AtScript and merging it with TypeScript 1.5, I would think that Aurelia will also drop AtScript?

I'm submitting a bug report

• Library Version:
  1.0.0

Please tell us about your environment:

• Operating System:
  Linux Ubuntu 14.04
• Node Version:
  v.4.5.0
• NPM Version:
  3.10.7

I'm submitting a bug report

• Library Version:
  1.0.3

Please tell us about your environment:

• Operating System:
  Windows 10

• Node Version:
  8.10.0

• NPM Version:
  6.0.1

• JSPM OR Webpack AND Version
  webpack ^4.8.3

• Browser:
  all

• Language:
  TypeScript 2.8.3

Current behavior:
Though I am not completely sure if this issue belongs here, at this point it seems that this is most relevant repository for this issue.

I am trying to unit test my simple custom elements, namely NormalText and ValueText, both of which inherits from BaseText. This is shown below.

// BaseText.ts
import { bindable } from "aurelia-framework";
import { BaseI18N } from "aurelia-i18n";

export class BaseText extends BaseI18N {
    @bindable public value: string;
    @bindable public i18nKey: string;
}

// NormalText.ts
export class NormalTextCustomElement extends BaseText { }

// ValueText.ts
export class ValueTextCustomElement extends BaseText { }

<!-- NormalText.html -->
<template>
    <span t.bind="i18nKey">${value}</span>
</template>

<!-- ValueText.html -->
<template>
    <strong t.bind="i18nKey">${value}</strong>
</template>

While trying to unit-test (Jasmine + Karma + Webpack) the views of these two custom elements, I ran into a problem, where metadata of the ViewModel class, whose test suite is running second had incorrect metadata. This is the reason why my second test suite is also failing.

For example, if the test suite for NormalText is ran first, then for the test suite of ValueText, metadata of ValueText reflected metadata of NormalText (the HTML/view resources of NormalText). More specifically, in this particular running example, there is no metadata directly in ValueText; and that's why the prototype of ValueText, in this case BaseText, is checked for metadata. When metadata of BaseText is checked, it returned information about the view of NormalText!!

A workaround can be to use @customElement decorator on both of these classes. I also asked about this problem in this SO question and reported the workaround.

Expected/desired behavior:

To reproduce the bug, one can check my GitHub repo. If you do so, then don't forget to remove the decorators.

• What is the expected behavior?
  As the name of custom elements stick to the conventions, it is expected that those custom elements should work without any decorators.

• What is the motivation / use case for changing the behavior?

In IE11, Object.getPrototypeOf breaks when it's passed a string.

@EisenbergEffect I don't see normalize in annotation.js. Do you think we should remove it from the expert?

export {getAnnotation, getAllAnnotations, addAnnotation, normalize} from './annotations'

Windows 7 x64
Typescript 1.6.0-beta or master branch same result
gulp-typescript 2.8.2

I am not sure if this is an aurelia issue or typescript. Note this same code works fine with Typescript 1.5.3

Here is the issue
Compiling this typescript
import {bindable} from 'aurelia-framework';

export class SeHeader {
@bindable router = null;

}

The js output line that is a problem is
__metadata('design:type', Object) this is what it is supposed to be and what ts 1.5 produces
However 1.6-beta produces
__metadata('design:type', ) missing the Object

the new mixin decorator is great, i maybe wrong, but it does not take into account the applied decorators on the mixed sources.

an example of that is that we want to create a custom element and eliminate boiler plate code like we dont want to define arguments in the constructor nor inject deps every time we create one, below is an example

@inject(Element, Service)
export class Component {
    constructor(element, service) {
        this.element = element;
        this.service = service;
    }

    render() {
        console.log(`render method is called`);
    }
}

@mixin(Component)
export class ComposedElement {
    constructor() {
        console.log(this.element);
        console.log(this.service);
        this.render();
    }
}

in above both this.element and this.service are undefined because they are not taking into account during mixin.

if (_key !== "default" && key !== "__esModule") _exportObj[_key] = _aureliaMetadata[_key];

need to be

if (_key !== "default" && _key !== "__esModule") _exportObj[_key] = _aureliaMetadata[_key];

this exists and in some others modules

I'm submitting a bug report

• Library Version:
  1.0.3

Please tell us about your environment:

• Operating System:
  Linux F27

• Node Version:
  8.9.4

• NPM Version:
  5.6.0

• JSPM OR Webpack AND Version
  webpack 4

• Browser:
  Chrome Version 65.0.3325.146 (Official Build) (64-bit)

• Language:
  TypeScript 2.7.2

Current behavior:

I just started using viewports in a few of my routing behaviours. The Chrome devtools console is giving me this warning:

aurelia-metadata.js?c04d:64 [Deprecation] 'window.webkitStorageInfo' is deprecated. Please use 'navigator.webkitTemporaryStorage' or 'navigator.webkitPersistentStorage' instead.
(anonymous) @ aurelia-metadata.js?c04d:64
(anonymous) @ aurelia-loader-webpack.js?b873:144
WebpackLoader.__WEBPACK_IMPORTED_MODULE_2_aurelia_pal__.PLATFORM.eachModule @ aurelia-loader-webpack.js?b873:141
get @ aurelia-metadata.js?c04d:61
getViewStrategy @ aurelia-templating.js?f83c:690
process @ router-view.js?e967:113
_loop @ aurelia-router.js?ec12:291
_commitChanges @ aurelia-router.js?ec12:305
(anonymous) @ aurelia-router.js?ec12:293
Promise.then (async)
_loop @ aurelia-router.js?ec12:291
_commitChanges @ aurelia-router.js?ec12:305
(anonymous) @ aurelia-router.js?ec12:293
Promise.then (async)
_loop @ aurelia-router.js?ec12:291
_commitChanges @ aurelia-router.js?ec12:305
run @ aurelia-router.js?ec12:143
next @ aurelia-router.js?ec12:112
iterate @ aurelia-router.js?ec12:1302
inspect @ aurelia-router.js?ec12:1279
(anonymous) @ aurelia-router.js?ec12:1295

It is specifically complaining about this line

Expected/desired behavior:

• What is the expected behavior?

The library should be updated to not use the deprecated functionality.

• What is the motivation / use case for changing the behavior?

Remove console deprecation warnings

Aurelia has it's own polyfills for metadata related features but Reflect.defineMetadata is buggy and creates problems.

The issue is that it uses ClassConstructor.__metadata__ as a backing storage without checking if it is its own field. This in turn means that a base class and all its sub-classes will share the same metadata store (at least with both TypeScript and Babel).

Here's what happen in details:

@autoinject
class B { }
class C extends B { }

When the code above is transpiled to ES5, both TS and Babel will create a function B and because of the attribute it will end up adding metadata to B through Reflect.defineMetadata.

With you implementation, this will get polyfilled as an object "dictionary" stored in B.__metadata__. So far so good.

Then when C extends B the static members of B are copied to C. TS and Babel differ here. TS simply copies every own key of B to C. Including __metadata__. Babel sets the prototype of C to B. Both have almost the same effect: reading C.__metadata__ will return B metadata storage.

And now those classes share the same metadata storage. For me the bug was exposed by this scenario: we have a base class for some view models. Aurelia caches view strategy into metadata. So depending on the order we browse our views, we ended up with a ViewModel incorrectly using another viewmodel's view. This is very bad!

I fixed the issues (temporarily) by providing my own polyfill of Reflect.defineMetadata. Specifically I changed this line:
https://github.com/aurelia/metadata/blob/master/src/metadata.js#L39
to:

var metaContainer = target.hasOwnProperty("__metadata__") ? target["__metadata__"] : (target["__metadata__"] = {});

The important difference here is that I only read the __metadata__ if it is the class' own property, not something coming from the prototype. Note that I believe this fixes the issue when using Babel only. Because Babel uses prototypes but TS simply copies the properties over, which means the fix is not going to work with TS.

For reference, rbuckton has implemented his polyfill using a WeakMap, which guarantees a distinct storage for each class, see:
https://github.com/rbuckton/ReflectDecorators/blob/master/Reflect.js#L23

This line https://github.com/aurelia/metadata/blob/master/src/metadata.js#L23 crashed when trying to load the module in a node environment.

Hi. This is a small thing, but going through metadata.js, there seems to be a type mismatch on a call to the Metadata.getOwn() function, when called by getOrCreateOwn(). I'm on v. 0.7.0.

In the argument list for getOwn(), the "target" is expected to be a Function. When called from getOrCreateOwn(), this "target" is a string, as is noted in the signature to getOrCreateOwn().

Sorry if I am reading this wrong. This is my first time through the code base.

I'm not sure if this is a bug in aurelia and if it's a bug at all but __metadata__ property is defined on object as enumerable so it's visible when enumerating over object and as a result in my case it gets stringified to json. Shouldn't it be hidden?

I have noticed an issue with @useShadowDOM and the latest release. It appears that shadow DOM is not working properly.

Please take a look at the following sample repository:

https://github.com/mattduffield/skeleton-navigation

I have created a TabControl and TabItem. I am preserving the folder structure of my larger application and just included these two controls for this issues. It turns out that if you use the @useShadowDOM in the TabItem js file, it no longer works. I believe that @PWKad has determined that this might be something with regard to the latest bootstrap version as my controls use Bootstrap.

I am more than happy to do it the correct way if there is something that I am doing wrong. I grabbed this code originally from @EisenbergEffect in one of the many posts he did on gitter.

I was trying to use aurelia DI on a node application and after installing all dependencies I got the following error:

dependency-injection-test/node_modules/aurelia-metadata/dist/commonjs/origin.js:16
if (!window.System) {
^
ReferenceError: window is not defined
at Object. (dependency-injection-test/node_modules/aurelia-metadata/dist/commonjs/origin.js:16:6)
at Module._compile (module.js:460:26)
at Module._extensions..js (module.js:478:10)
at Object.require.extensions.(anonymous function) as .js
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)
at require (module.js:384:17)
at Object. (dependency-injection-test/node_modules/aurelia-metadata/dist/commonjs/index.js:5:15)
at Module._compile (module.js:460:26)

After commenting the if I get the following error:

if (!System.forEachModule) {
^
ReferenceError: System is not defined
at Object. (dependency-injection-test/node_modules/aurelia-metadata/dist/commonjs/origin.js:20:6)
at Module._compile (module.js:460:26)
at Module._extensions..js (module.js:478:10)
at Object.require.extensions.(anonymous function) as .js
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)
at require (module.js:384:17)
at Object. (/dependency-injection-test/node_modules/aurelia-metadata/dist/commonjs/index.js:5:15)
at Module._compile (module.js:460:26)

If I declare a var System = { }; before that if everything works correctly.

I'm running the application with babel-node --stage 0

We are using aurelia-metadata 1.3.0 for a while. Suddenly our project is not buildable because aurelia-pal typings have changed recently and are no longer compatible with Typescript 2.5 we are currently using. Upgrading typescript will probably fix this issue, but I think release packages should be "immutable".

I'm submitting a bug report

• Library Version:
  1.0.3

Please tell us about your environment:

• Operating System:
  Windows 10

• Node Version:
  6.12.0

• NPM Version:
  3.10.10

• JSPM OR Webpack AND Version
  JSPM 0.16.38

• Language:
  TypeScript 2.6.2

Current behavior:
Our CI and local builds suddenly started to fail with the following error:

Error: typings/modules/aurelia-metadata/index.d.ts(342,33): 
error TS2304: Cannot find name 'SVGElementTagNameMap'.

Currently we don't have any clue what might be causing this. Any ideas?

After upgrading to bootstrapper 0.13.1 (and all its dependencies, including metadata 0.6.0), I am now unable to bootstrap my code.

I am using requirejs (AMD) as my loader, within a browser. I import aurelia-bootstrapper, which loads aurelia-framework, which loads aurelia-metadata. Once these dependencies are ready, boostrapper.run() calls ensureLoader(), which checks whether System exists, then tries to load via the System loader..

Which results in an error "System.normalize is not a function".

Obviously this is a problem, since window.System was an object created within metadata, NOT the loader

I'm submitting a bug report
I'm submitting a feature request

• Library Version:
  major.minor.patch-pre

Please tell us about your environment:

• Operating System:
  OSX 10.x|Linux (distro)|Windows [7|8|8.1|10]

• Node Version:
  6.2.0

• NPM Version:
  3.8.9

• JSPM OR Webpack AND Version
  JSPM 0.16.32 | webpack 2.1.0-beta.17

• Browser:
  all | Chrome XX | Firefox XX | Edge XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView

• Language:
  all | TypeScript X.X | ESNext

Current behavior:

Expected/desired behavior:

• What is the expected behavior?

• What is the motivation / use case for changing the behavior?

Should aurelia-metadata list aurelia-polyfills as peerDeps? It is used here and here

it would be great to add more customization and flexibility to the framework by being able to plug custom metadata and use it like C# Attributes style