Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[AssetMapper] Flexible public paths + relative path imports + possibility of "building" assets#50264

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged

Conversation

@weaverryan
Copy link
Member

QA
Branch?6.3
Bug fix?no
New feature?yes
Deprecations?no
TicketsNone
LicenseMIT
Doc PRStill a TODO in general

Hi!

Working hard to see where AssetMapper adjustments need to be made. 3 changes proposed here:

  1. AssetMapper's "public output path" awareness was moved to a newPublicAssetsPathResolver service
  2. The asset compilers were updated to use relative paths when adjusting paths in files.
  3. Drop the "mime type" stuff entirely - except for the "dev server" so it can set the content-type. Asset compiler's can use$mappedAsset->getPublicExtension() instead.

Why these changes?

  1. Allow public/assets/ structure to flatten/change

The newPublicAssetsPathResolver + the "adjustment" of import/url paths in the compilers allows the "output" directory structure to be decoupled from the source structure. Currently the output structure matches your "source" structure, so you get things likepublic/assets/styles/app.css orpublic/assets/bundles/easyadmin/foo.css. We could add an option in the future (or the user could decoratePublicAssetsPathResolver immediately) to "flatten" everything into justpublic/assets/.

  1. Allow for building of certain files, like.scss or.jsx

These changes allow users to create... more controversial functionality that could build certain files automatically. For example, you could have:

<linkrel="stylesheet"href="{{ asset('styles/app.scss') }}">

Locally, I have a custom compiler that executes thedart-sass binary to convert this to CSS. Then, by decoratingPublicAssetsPathResolver, I'm changing the public path forstyles/app.scss so that it ends with.css. This is about 50 lines of code that results in the sass-compiled CSS file being properly rendered onto the page.

I have a similar compiler + path decorator locally that compiles.jsx =>.js using the babel binary. Usage:

// assets/app.jsimportHelloWorldComponentfrom'./HelloReact.jsx';// ... render like normal

I realize usage like this is more controversial... however it's also super pragmatic if you DO use Sass or have some React components. The alternative would be to run thesass binary manually, import the built.css file and probably ignore that file fromgit.

Thanks for your consideration :).

Cheers!

Copy link
Member

@javiereguiluzjaviereguiluz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

After thinking about this, I changed my initial thoughts and now I'm 👍 about this.

It's true that it's controversial and the"you are recreating Assetic" argument is half-true .... but at the same time:

  • Without any utility to build SCSS into CSS, I can't use AssetMapper. I'd stick to Webpack, Encore, node.js, etc.
  • My current usage of SCSS is minimal(and from what I've seen, for many other Symfony developers is the same)
  • In fact, my only current reason for using SCSS is selector nesting. This is already a native browser feature (https://caniuse.com/css-nesting) so, as soon as there's more support for it, I'll remove SCSS and just use plain CSS.

So, this "controversial" feature would be useful for me during the 1 or 2 year transition from today until I can stop using SCSS and move to CSS.

Thanks Ryan!

weaverryan reacted with heart emoji
@fabpot
Copy link
Member

Thank you@weaverryan.

@fabpotfabpot closed thisMay 12, 2023
@fabpotfabpotforce-pushed theasset-mapper-public-path-resolving branch from58830ca to53e297dCompareMay 12, 2023 07:10
@fabpotfabpot merged commite3a816d intosymfony:6.3May 12, 2023
@weaverryanweaverryan deleted the asset-mapper-public-path-resolving branchMay 12, 2023 09:44
fabpot added a commit that referenced this pull requestMay 13, 2023
This PR was squashed before being merged into the 6.3 branch.Discussion----------[AssetMapper] Add cached asset factory| Q             | A| ------------- | ---| Branch?       | 6.3| Bug fix?      | no| New feature?  | yes| Deprecations? | no| Tickets       | None| License       | MIT| Doc PR        | Still TODOHi!This is built on top of#50264. I CAN separate them if needed - sorry for the noise.tl;dr When using asset mapper, to load the page, we need to build the importmap & resolve a few paths, like `{{ asset('styles/app.css') }}`. Because asset mapper loads the contents and performs some regex on CSS and JS files, this can slow down the page in dev (in prod, `asset-map:compile` removes all overhead).This PR fixes that (I can see a big improvement in my test app). We "cache" the `MappedAsset` objects via the config cache system so that if an underlying file changes (e.g. `assets/styles/app.css`), we only need to rebuild that ONE `MappedAsset` when the page is loading.Cheers!Commits-------ce77ed8 [AssetMapper] Add cached asset factory
@fabpotfabpot mentioned this pull requestMay 13, 2023
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@javiereguiluzjaviereguiluzjaviereguiluz approved these changes

@stofstofstof approved these changes

Assignees

No one assigned

Projects

None yet

Milestone

6.3

Development

Successfully merging this pull request may close these issues.

5 participants

@weaverryan@fabpot@javiereguiluz@stof@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp