update docs

docs/advanced-usage.md

@@ -52,15 +52,15 @@ export function bar() {
 </script>
 ```
 
-## Using `_import()` in a script tag without `type="module"`
+## Using `_import` in a script tag without `type="module"`
 
-All previous examples have used the `_import()` function within a script tag with `type='module'`. This instructs the browser to treat the containing code as a module. Practically this means that code gets it's own namespace & you can't reach for variables outside the scope of the script tag.
+All previous examples have used the `_import` function within a script tag with `type='module'`. This instructs the browser to treat the containing code as a module. Practically this means that code gets it's own namespace & you can't reach for variables outside the scope of the script tag.
 
-A script tag with `type="module"` makes your script `defer` by default, so they are loaded in parallel & executed in order. Because of this the `_import()` function has your requested module available immediately. (Since they are loaded in the same order they appeared in the DOM)
+A script tag with `type="module"` makes your script `defer` by default, so they are loaded in parallel & executed in order. Because of this the `_import` function has your requested module available immediately. (Since they are loaded in the same order they appeared in the DOM)
 
 This is not the case however when you use a script tag without `type="module"`. A import might still be loading while the page encounters the `_invoke()` function.
 
-Bundle takes care of this problem by checking the internal import map by use of a non-blocking polling mechanism. So you can safely use `_import()` anywhere you want.
+Bundle takes care of this problem by checking the internal import map by use of a non-blocking polling mechanism. So you can safely use `_import` anywhere you want.
 
 Since Bundle's core is included with the first `<x-import />` that you load you do have to either wrap the import inside a `DOMContentLoaded` listener or make the import inline.
 
@@ -76,11 +76,11 @@ Since Bundle's core is included with the first `<x-import />` that you load you
 
 {: .note }
 
-> We like to explore ways to inject Bundle's core on every page. This way the `_import()` function does not have to be wrapped in a `DOMContentLoaded` listener. Check out our [roadmap](https://laravel-bundle.dev/roadmap.html#roadmap) to see what else we're cooking up.
+> We like to explore ways to inject Bundle's core on every page. This way the `_import` function does not have to be wrapped in a `DOMContentLoaded` listener. Check out our [roadmap](https://laravel-bundle.dev/roadmap.html#roadmap) to see what else we're cooking up.
 
 ## Import resolution timeout
 
-The `_import()` function uses a built-in non blocking polling mechanism in order to account for async & deferred script loading. The import resolution time may be configured milliseconds by updating the config file or via an env variable `BUNDLE_IMPORT_RESOLUTION_TIMEOUT`. This will instruct Bundle how long the `_import()` function should wait untill a module is loaded.
+The `_import` function uses a built-in non blocking polling mechanism in order to account for async & deferred script loading. The import resolution time may be configured milliseconds by updating the config file or via an env variable `BUNDLE_IMPORT_RESOLUTION_TIMEOUT`. This will instruct Bundle how long the `_import` function should wait untill a module is loaded.
 
 ## Minification
 

docs/caveats.md

@@ -23,7 +23,7 @@ If we were able to add code splitting we would be able to chunk these shared mod
 Due to Bun's path remapping behaviour Bundle is not able to split chunks from modules and assets imported from a path below it's internal project root (which is in the storage directory). If Bun fixes this issue this feature might be possible in the future.
 
 <!-- TODO: Add a detailed treeview of chunking vs how it's done now -->
-<!-- NOTE: A workaround where your local scripts also use _import() & we preload all dependencies in the blade template is possible. But less than ideal. -->
+<!-- NOTE: A workaround where your local scripts also use _import & we preload all dependencies in the blade template is possible. But less than ideal. -->
 
 ## Don't pass dynamic variables to `<x-import />`
 

docs/introduction.md

@@ -13,22 +13,19 @@ The `<x-import />` component bundles your import on the fly using [Bun](https://
 
 <!-- yields the following script -->
 
-<script
-  src="/x-import/e52def31336c.min.js"
-  type="module"
-  data-module="alert"
+<script src="/x-import/e52def31336c.min.js" type="module" data-module="alert" data-alias="ApexCharts"
 ></script>
 ```
 
 <br />
 
 {: .note }
 
-> You may pass any attributes a script tag would accept, like `defer` or `async`
+> You may pass any attributes a script tag would accept, like `defer` or `async`. Note that scripts with `type="module"` are deferred by default.
 
 <br />
 
-## The `_import()` helper function
+## The `_import` helper function
 
 After you use `<x-import />` somewhere in your template a global `_import` function will become available on the window object.
 
@@ -50,6 +47,8 @@ _In cases like this it might be advantagious to use per-method imports instead.
 
 The `_import` function is async & returns a Promise. In order to use this in inline scripts you need to wrap it in a async function, or make the script tag you are using it in of `type="module"`.
 
+It's recommended to use a inline script of type `module`. This makes it deferred by default & instructs the browser to run those tags sequentially. If you use a script without the `module` type you can still use Bundle, but with some extra boilerplate. [Check here](https://laravel-bundle.dev/advanced-usage.html#using-_import-in-a-script-tag-without-typemodule) if you'd like to learn more
+
 Refer to the [local modules](https://laravel-bundle.dev/local-modules.html) docs for a more detailed explanation on how the `_import` function can be utilized in different scenarios.
 
 <br />

docs/local-modules.md

@@ -59,7 +59,7 @@ export default (() => {
 })();
 ```
 
-Then in your template you can use the `<x-import />` component to evaluate this function. Without the need of calling the `_import()` function. Note this only works with a [IIFE](https://developer.mozilla.org/en-US/docs/Glossary/IIFE){:target="\_blank"}
+Then in your template you can use the `<x-import />` component to evaluate this function. Without the need of calling the `_import` function. Note this only works with a [IIFE](https://developer.mozilla.org/en-US/docs/Glossary/IIFE){:target="\_blank"}
 
 ```html
 <!-- User will be alerted with 'Hello World' -->

docs/roadmap.md

@@ -94,7 +94,7 @@ It would be incredible if this object could be forwarded to Alpine directly like
 
 ## Injecting Bundle's core on every page
 
-This will reduce every import's size slightly. And more importantly; it will remove the need to wrap `_import()` calls inside script tags without `type="module"`, making things easier for the developer and greatly decrease the chance of unexpected behaviour caused by race conditions due to slow network speeds when a `DOMContentLoaded` listener was forgotten.
+This will reduce every import's size slightly. And more importantly; it will remove the need to wrap `_import` calls inside script tags without `type="module"`, making things easier for the developer and greatly decrease the chance of unexpected behaviour caused by race conditions due to slow network speeds when a `DOMContentLoaded` listener was forgotten.
 
 ## Better exception messages