I have 3 scripts in the "Injected Content/End Scripts" section of my extension. Only one particular script is not being injected.
I removed all 3 scripts and injected each one individually, only a particular script is not being loaded via the injected content section while the other two load just fine.
Is there any reason why a particular script might not get injected?
I had a syntax error in that script that prevented it from being loaded by the safari extension builder.
There doesn't seem to be a way to debug syntax errors in injected scripts other than having your linter on in your editor.
Related
I'm trying to follow the Compose Multiplatform Web Getting Started guide. Most of it seems to work fine, but when I try to actually run the thing (gradle jsBrowserRun), it starts a browser, but it can't find the generated JavaScript file. The browser console shows a 404 for GET http://localhost:8080/kotlin-multi-web.js.
The file kotlin-multi-web.js is indeed the name of a file generated in web/build/compileSync/main/developmentExecutable/kotlin.
The page title matches the one I defined in my index.html, so that gets loaded correctly.
I have tried a pure Compose Web project (which isn't a Gradle multi module project), and there it does all load correctly. I checked, and didn't see any differences between the Gradle build files other than the extra dependency from the web project on common.
So, why doesn't it load, and how can I fix it?
What I wanna achieve ?
When any .php file is saved, it checks the file and checks for unused use statements.
How can I parse or somehow get the list of unused use statements in the file without custom code analysis ? The PHPStorm does it with the php plugin. Can I get it from it? The documentation is realy bad and I was not able to find anything.
I have the php plugin dependency in my plugin.xml
<depends>com.jetbrains.php</depends>
It would be great if i could parse the whole php file and access information about use statements, fucntions, classes etc.
I'm experimenting with Vite, VueJS 3 and vite-plugin-singlefile for an app which is bundled to a single HTML file, and then served inside a sandboxed iframe through a parent site I don't have much control to change.
Specifically, the iframe runs sandboxed with <iframe src="someotherorigin/page.html" sandbox="allow-scripts allow-same-origin allow-forms">. My built HTML page references some external scripts via CDN (e.g. Bootstrap, etc), but the actual app code itself is inlined.
The app works fine with Vite's dev server and build+serve option. It's also fine when I preview in other tools... But in the target environment it seems like the main entrypoint script simply doesn't run. Nothing renders but also no error messages in console. I do get a couple of warnings about malformed CSP, but that's all:
Content Security Policy: Interpreting none as a hostname, not a keyword. If you intended this to be a keyword, use 'none' (wrapped in single quotes).
Content Security Policy: Interpreting https://none as a hostname, not a keyword. If you intended this to be a keyword, use 'none' (wrapped in single quotes).
This question got me curious so I tried manually editing the built index.html to change the inlined <script type="module">...</script> to <script>...</script> - And it works fine!
...But:
I can't make that change in the source index.html (Vite just ignores & refuses to bundle the TypeScript /src/main.ts source unless "module" is set)
I don't think there's an easy way to automate changing it in the build pipeline either (seems like it'd be messing around with custom Vite plugins)
I don't really understand what's wrong in the first place - why would type="module" cause the iframe not to run this Vue-generated script? Is there some other more proper fix?
My changes are not reflecting inside browser even after storage/framework/views clear and running various artisan clean-up commands.
To make clear that I am calling the right file.
Is it possible my PHP environment is somehow persistent loading this file?
I found the answer.
I am using Nwidart/LaravelModules to structure my project.
Laravel Modules has a command that publishes all modules to the views folder in resources/views. Apparently Laravel was using those 'published modules' alongside the 'official' modules, which caused the problem above.
Is it possible to use Dojo build without the need to modify JavaScript files?
The article dgrid and Dojo Nano Build provides the instruction to create the build, but it requires adding the following line into JavaScript file, which initializes the application:
require(['dgrid/dgrid'], function () {
(replacing 'dgrid/dgrid' with your build module name).
However, it is very problematic when using build for own modules, because, of course, in development mode the require with own layer can't be included, otherwise the modifications made to own modules wouldn't be visible. But in production mode this line must be added.
So either you must modify the file manually before production build, or write a script that would modify the file during the build. Both are very error-prone.
Is there a better way to achieve that result? Is it possible for Dojo to recognize that the build is provided and should be used, instead of loading each module separately?
The following line of code can be included in both development and production modes.
require(['dgrid/dgrid'], function () {
I describe the reasons why in my answer here.
What you need to do is configure Dojo differently based on what environment.
In a blog post that I wrote, I describe this in more detail. The following summarizes the post:
I create three modes: Production, Uncompressed, and Development.
Development
When developing code, I will have the js source linked into the web server and the Development mode will point to the dojo.js file and the raw css file(s). The browser will load modules that I need using xhr. And I point to the top level css files which import other css files. The result is that a lot of requests will be made to the server and the loading of the page will be noticeably slow. The benefit is that you can see development changes without having to do a full build.
Production
Production mode points the main dojo file at the dojo.js that is built using the build tool. I also create <script> elements for the other layers that are needed in the page. I point the css to the built css files which the build tool has inlined the imported css. The page loads quickly, but it is difficult to debug
Uncompressed
Similar to production, but I point to the .uncompressed.js files. Production and Uncompressed are available in the released version of our software. I use uncompressed when trying to troubleshoot an issue in a production environment. The value of this mode is dwindling as the developer tools are better supporting compressed javascript (ie source maps, etc.)
Server side
The default mode is Production, but I use a query parameter to switch modes. I also store the current mode in the session, so that I only have to set the mode once to change it. Subsequent pages will run in the changed mode, until I change it back.
Here is a java implementation of this code.