Convert some more curly bracket links

import-example: update to glimmer

Let's update the ImportExample component to extend glimmer/component instead of ember/component. Glimmer components offer a bunch of various advantages over classic components and are the direction that ember is heading in general.

import-example: prefer single quotes

Let's prefer single quotes to double quotes throughout our template file.

project-version: avoid unnecessary arg to TOC

Let's avoid passing the 'projectId' argument to the TableOfContents component as it does not do anything with it.

table-of-contents: convert to glimmer

Let's update the TableOfContents component to extend glimmer/component instead of ember/component. Glimmer components offer a bunch of various advantages over classic components and are the direction that ember is heading in general.

table-of-contents: prefer single quotes

Right now, we mix both single quotes and double quotes throughout the template file. Let's prefer single quotes instead.

tests: import-example: prefer angle syntax

Let's prefer to use angle bracket syntax rather than curly brace syntax in our tests which create an ImportExample component.

tests: table-of-contents: prefer angle syntax

Let's prefer angle bracket syntax to curly syntax when invoking the TableOfContents component in our integration tests. This will fix deprecation warnings about using the latter, which make the test results a bit harder to decipher.

loading-spinner: convert to glimmer

Let's update the LoadingSpinner component to extend glimmer/component instead of ember/component. Glimmer components offer a bunch of various advantages over classic components and are the direction that ember is heading in general.

loading-spinner: prefer single quotes

Let's prefer to use single quotes throughout the loading-spinner template file as our Prettier config will attempt this conversion upon save anyway.

tests: loading-spinner: prefer angle bracket syntax

Let's prefer angle bracket syntax to curly syntax when invoking the LoadingSpinner component in our integration tests.

dropdown-header: convert to glimmer

Let's update the DropdownHeader component to extend glimmer/component instead of ember/component. Glimmer components offer a bunch of various advantages over classic components and are the direction that ember is heading in general.

dropdown-header: prefer single quotes

Let's prefer to use single quotes throughout the dropdown-header template file as Prettier will attempt this conversion upon save anyway based on the current configuration.

Bump shell-quote from 1.7.2 to 1.7.3

Bumps shell-quote from 1.7.2 to 1.7.3.

• Release notes
• Changelog
• Commits

updated-dependencies:

• dependency-name: shell-quote dependency-type: indirect ...

Signed-off-by: dependabot[bot] support@github.com

search-input: update to glimmer

Let's update the SearchInput component to extend glimmer/component instead of ember/component. Glimmer components offer a bunch of various advantages over classic components and are the direction that ember is heading in general.

While we're here, let's also re-enable the eslint rules for which the SearchInput component had the only violations.

tests: search-input: use render helper

Ember's this.render method and @ember/test-helpers's render method are equivalent, but using @ember/test-helpers' render method is the recommended approach. As such, let's go ahead and switch this over.

While we're here, let's re-enable this eslint rule as we no longer have any violations.

tests: search-input: prefer angle bracket syntax

Let's prefer angle bracket syntax to curly syntax when invoking the SearchInput component in our integration tests.

Merge branch 'master' into update-import-example-component-to-glimmer

Merge branch 'master' into update-loading-spinner-component-to-glimmer

Merge branch 'master' into update-dropdown-header-component-to-glimmer

Update: adding the following fixes that issue

  "dependenciesMeta": {
    "addon-name": {
      "injected": true
    }
  },

so this was definitely the problem 🙈

Firstly thank you for the dependenciesMeta.*.injected tip, this is most likely exactly what I need (here is the link if anyone else is following along)

I'll try this out and let you know if it fixes my issue... but I'm a little bit concerned about the discoverability of this for the wider population. I didn't set up this monorepo, in fact the people that did that are way smarter than me in every way that I can count, but doing a quick search there is exactly zero use of this feature anywhere in the monorepo and from what you're saying it practically needs to be in every single package.json 😱

I don't know what the answer is... but even if it were possible to give a suggestive error that people could follow a link to a FAQ or something that would make me much happier about this situation. What do you think?

Before:

After:

In fact I just solved my problem with an even worse workaround 🙈 I now have 2 yMarkers:

yMarkers: [
        {
            label: '',
            value: 0,
            type: 'solid'
        },
        {
          label: '',
          value: 5,
          type: 'solid'
        }
    ]

and that will prevent partial numbers from showing in the graph. And since I really don't have a need for numbers I'm just ignoring them always with CSS:

.frappe-chart .y-markers {
  display: none;
}

It's not a great solution, and you can't use it if you ever want to actually use markers but 🤷

so It's been so long for me that I'm not sure which issue is referring to what any more 🙈 @mathiasbynens I looked at my code and it does seem to make sure that all graphs have a 0 in them if that's what you're hoping the workaround does

In my case I would love a way to properly influence the Y axis and make it not show 0.25 entries when my graph has a high number of 1 😞

So I'm not exactly familiar with that plugin but it looks like it's taking a different approach to dealing with large numbers of existing errors.

I would recommend trying to remove that plugin, run lint-to-the-future ignore and see if switching from eslint-plugin-only-warn to Lint to the Future is a viable option

This issue has hit me for a little while, and after our last Embroider meeting, I am finally at the point where I feel confident enough to open the issue about this 😂 still quite a while until I understand how to fix the problem though 😭

I'm going to say it from the start because I think it's relevant to the problem: We are using pnpm in a monorepo when I'm seeing this problem.

The error that I've been facing is the following:

Build Error (PackagerRunner) in ../../addons/addon-name/test-support/accordion.js

Module not found: Error: Can't resolve '@ember/test-helpers' in '$TMPDIR/embroider/62cd22/addons/addon-name/test-support/accordion.js'

Note: I have replace the real addon name with <addon-name> as it's an internal addon 👍

When discussing this in the #embroider-dev channel on discord the first thing that people suggested was for me to "make sure that I have the same version of @ember/test-helpers everywhere" so I run pnpm why @ember/test-helpers and get the following output:

devDependencies:
@ember/test-helpers 2.9.3
ember-a11y-testing 5.0.0
└── @ember/test-helpers 2.9.3 peer
ember-qunit 6.0.0
└── @ember/test-helpers 2.9.3 peer

so that's totally fine.

When looking at the folder that error says it can't resolve the dependency $TMPDIR/embroider/62cd22/addons/addon-name/test-support/ and following the node resolution rules I find that the place it would try to import from is $TMPDIR/embroider/62cd22/addons/addon-name/node_modules/@ember/test-helpers and running ls in that folder I see that it's mostly empty:

➜  test-helpers ls
package.json

and the contents of the package.json are incredibly sparse i.e. just the name field:

➜  test-helpers cat package.json
{"name":"@ember/test-helpers"}

After the embroider meeting it's clear that this empty package is being exported by the build-compat-addon file in the @embroider/compat package: https://github.com/embroider-build/embroider/blob/main/packages/compat/src/build-compat-addon.ts#L37

Now that I know where the problem was coming from I dropped a debugger in there to find out why the issue was happening.

The key to this problem is related to the v1Cache and the line let oldPackages = v1Cache.getAddons(originalPackage.root);

I don't exactly know what is going on here but the first time it goes through this code path with originalPackage.name === '@ember/test-helpers' there are no problems. The originalPackage.root is a pointing at a directory in my node modules (with a bit of specific flare for pnpm)

~/git/company-name/product-name/node_modules/.pnpm/@ember+test-helpers@2.9.3_g5joarsmjni6reqiie7sf6wauy/node_modules/@ember/test-helpers

and when the oldPackages is queried in the cache it finds it and works correctly, no problems with EmptyPackageTree being output 👍

The second time that it comes through this code path when originalPackage.name === '@ember/test-helpers' we have a problem because the originalPackage.root is different. The strange pnpm suffix has changed:

~/git/company-name/product-name/node_modules/.pnpm/@ember+test-helpers@2.9.3_2lbu44dmrdozuoe4jwbycbgazy/node_modules/@ember/test-helpers

and this results in a cache miss because there is only one entry in the v1Cache.addons for @ember/test-helpers 😞

Before noticing this issue I didn't really know why pnpm adds these suffixes and it seems like it's related to this document: https://pnpm.io/how-peers-are-resolved

My naive (and potentially wrong) understanding is that pnpm creates a new copy of the @ember/test-helpers dependency for each discovered difference in the set of peer-depencencies of that dependency. As @ember/test-helpers only has one peer-dependency (ember-source) I tried pnpm why ember-source to see if there was any difference and I couldn't see any:

devDependencies:
@ember/test-helpers 2.9.3
├─┬ @embroider/util 1.9.0
│ └── ember-source 4.9.3 peer
└── ember-source 4.9.3 peer
ember-a11y-testing 5.0.0
└─┬ @ember/test-helpers 2.9.3 peer
  ├─┬ @embroider/util 1.9.0
  │ └── ember-source 4.9.3 peer
  └── ember-source 4.9.3 peer
ember-qunit 6.0.0
└─┬ @ember/test-helpers 2.9.3 peer
  ├─┬ @embroider/util 1.9.0
  │ └── ember-source 4.9.3 peer
  └── ember-source 4.9.3 peer
ember-source 4.9.3

I thought as a last-ditch attempt, why don't I diff the full folders of the @ember/test-helpers in the pnpm directory with different suffixes and that showed up the following:

Note: I am filtering the output here to only show the diffs, there is a lot the same but there are clearly some differences.

This is where I am once again lost on how to continue. I don't understand why pnpm why would show no difference for either @ember/test-helpers or ember-source but there are clearly differences in the tree somewhere.

I also am not sure if this is a limitation in pnpm or embroider 🤔 should the v1Cache.addons list both (all?) pnpm versions of @ember/test-helpers? Or maybe should the lookup ignore this strange suffix that pnpm adds and count both cases as a cache hit for the same dependency?

Essentially I'm trying to think of a way forward for this issue to prevent it from happening again. In my case I rebased my embroider branch on develop and the problem went away because more things had updated to ember-source@4.10 so the duplication went away, but I can see this issue cropping back up again at random intervals (maybe close to an ember release week).

@ef4 do you think that the resolver refactor that you're doing would fix this?

Fixed nestedproblems based on latest knowledge

Merge pull request #11 from mainmatter/nested-leaking-fix

Fixed nestedproblems based on latest knowledge

Fixed example with :generated pseudo-class

I don't even know if this is the right place for this but I figured we could discuss this on the PR 👍

Fixed nestedproblems examples

Merge pull request #10 from mainmatter/fixed-nested-leaking

Fixed nestedproblems examples

Fixed nestedproblems examples

Generated function based on css file

Only classes in a css file will be renamed.

Merge pull request #9 from mainmatter/generated-based-on-css

Generated function based on css file

Only when a class is defined in CSS file, then it will be rewritten. So function generate needs to get CSS file as an argument.

.first :generated(.second, 'components/second.css'){ ... }

start using ember-cli-netlify

add /number/num netlify redirects

Merge pull request #12 from ember-learn/netlify-redirects

Add /number/num Netlify redirects for easier access to RFCs

This was a feature request form @kategengler 🎉

This adds Netlify redirects in the format /number/:num that redirect to the canonical url for the RFC with its full ID.

E.g. https://deploy-preview-12--ember-rfcs.netlify.app/number/659 redirects to https://deploy-preview-12--ember-rfcs.netlify.app/id/0659-unique-id-helper

Note: there are some RFCs that share the same number (from the ember-cli rfc merger) and as there are so few of them we didn't implement any special behaviour. For these RFCs the behaviour is undefined, and that's ok 😂