-
Notifications
You must be signed in to change notification settings - Fork 9
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Docs] More explicit usage examples #44
base: main
Are you sure you want to change the base?
[Docs] More explicit usage examples #44
Conversation
For instance, if your TypeScript code lives in ``assets/typescript/`` directory, | ||
with an ``assets/typescript/app.ts`` entrypoint file, set the option like this: | ||
|
||
.. code-block:: yaml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to the new defaults to ...
text added above, I'd keep the original config example too to make it more clear:
.. code-block:: yaml
# config/packages/asset_mapper.yaml
sensiolabs_typescript:
source_dir: ['%kernel.project_dir%/assets/typescript']
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if this already works ... but if "not"
I think you should allow a path or an array of paths there... (we did it in the sassbundle some time ago if you want to have a look and avoid time on doc :) )
Little thing, but still a DX improvement some people enjoy :)
(well... me at least 😅 )
{% block javascripts %} | ||
<script type="text/javascript" src="{{ asset('typescript/app.ts') }}"></script> | ||
{% endblock %} | ||
There are three ways to use your TypeScript files using this bundle: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd add a short example of how to use each of these three ways.
This way you can add short but useful explanations if needed. For example:
By including a raw file in your templates ``<script type="module" src="{{ asset('app.ts') }}"></script>``
Could be something similar to https://symfony.com/doc/current/frontend/asset_mapper.html#mapping-and-referencing-assets
Including a Raw TypeScript File in the Template
-----------------------------------------------
Use the `asset() Twig function`_ to link to TypeScript files from any Twig
template:
.. code-block:: twig
<script type="module" src="{{ asset('app.ts') }}"></script>
The path - ``app.ts`` - is relative to the directory configured in the
``sensiolabs_typescript.source_dir`` option. This is known as the logical path
to your asset.
If you look at the HTML in your page, the actual URL will be something like:
``/assets/app-3c16d9220694c0e56d8648f25e6035e9.ts``. If you change the file,
the version part of the URL will also change automatically.
.. _`asset() Twig function`: https://symfony.com/doc/current/reference/twig_reference.html#asset
<script type="text/javascript" src="{{ asset('typescript/app.ts') }}"></script> | ||
{% endblock %} | ||
There are three ways to use your TypeScript files using this bundle: | ||
* By defining TypeScript files as **entrypoints** in ``importmap.php``, then using the `importmap() Twig function <https://symfony.com/doc/current/frontend/asset_mapper.html#how-does-the-importmap-work>`_. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would not recommand this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't either, but if the application entrypoint is a typescript file ("app.ts") or if there is a real need for another entrypoint (since it's documented in the AssetMapper documentation) I think we should mention it.
But maybe we could change the order or the options, or mention that the best practice is to have a single entrypoint and import files from there, or use stimulus controllers for context-specific files ?
@@ -81,7 +67,7 @@ The first time you run one of the TypeScript commands, the bundle will download | |||
the correct SWC binary for your system into the ``var/`` directory. | |||
|
|||
When you run ``typescript:build``, that binary is used to compile TypeScript files | |||
into a ``var/typescript/`` directory. Finally, when the contents of ``assets/typescript/app.ts`` | |||
into a ``var/typescript/`` directory. Finally, when the contents of ``assets/app.ts`` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this realtime ? Or deployed once ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's compiled once or using the watch option, no real-time compiling at the moment (and not planned).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant the "Finally, when the content is requested, the bundle swaps the contents of that file ...."
Is this done "when the content is requested" or only once on asset mapper deploy ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works leveraging AssetMapper : it's swapped when running asset-map-compile
(you'll only have js files in the public/assets
directory) or on the fly in dev mode.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really need to improve my communication... :))
What i wanted to point out is, the sentence "when the content is requested, the bundle swaps the contents " could be missleading for the user, and maybe should be replaced, as you just said, by something like
"In dev, ..... bla bla bla in real time. In prod, during deployment ...." :)
We had a few issues opened by people who were confused on how to use the bundle.
The example in the doc was not using the standard "entrypoint / importmap" method from the AssetMapper component, and there was no mention of the ability to import TypeScript files from other JS/TS files.
The doc should definitely be more explicit on what the bundle can do and how to do it.
This is an attempt to clear things up, but I'm no documentation expert so any input would be appreciated :)