I have started a project with parcel. Locally it works perfectly but when I want to deploy the page to GitHub Pages I have some issues.
Once compiled and uploaded, the browser tries to look for a css and js file that do not exist and does not take the styles created in /dist.
Code image of index.html
File it tries to find
Another error is this:
Refused to apply style from 'http://127.0.0.1:5500/index.d4b38681.css'
because its MIME type ('text/html') is not a supported stylesheet MIME
type, and strict MIME checking is enabled.
How do I configure parcel to take the files from /dist when deploying?
Related
I want to publish my Svelte web app to GitHub pages and based my application on the template https://github.com/sveltejs/template. When I run npm run build, public/build/bundle.js is created but no index.html. All the tutorials I found talk about how to deploy Sapper projects, or to use external tools like Vercel and Surge, but is it possible to just build Svelte without any external tools? All I want is a static HTML page that I can copy to GitHub pages.
Edit: See the accepted answer for the general approach, however for non-root-directory-deployment, you still need to make the paths relative. I created a pull request at https://github.com/sveltejs/template/pull/239.
In svelte, index.html is a static file which will import your bundle.js and run it.
index.html is located at /public/index.html while your bundle.js is located at /public/build/bundle.js
in svelte template, index.html imports /build/bundle.js using a script tag to initialize the application.
while deploying, you just need to upload the whole /public folder and everything should be operational.
I'm learning Aurelia via the TypeScript / ASP.NET Core skeleton navigation app. Everything runs fine in its default state. To test the exported production bundle, I run the Gulp Export task, then publish the app via Visual Studio project publish to a local folder, then replace the published wwwroot folder with the wwwroot folder from within the "export" folder, then use dotnet from the command line to run the app.
Things break if I have any source modules in a subdirectory. For example, I moved the welcome.ts/html component files into "/src/Pages" and adjusted its route moduleId in app.ts accordingly to "./pages/welcome". The unbundled app then still runs up fine, but when I try the exported version, I get a request being made by SystemJS to http://localhost:5000/dist/pages/welcome.js which 404s (as you'd expect).
I can see the contents of the welcome component in the app-build.js file, and the config.js file within the export folder contains the expected file paths, i.e. it has "Pages/welcome...".
I have read this seemingly similar issue:
https://github.com/aurelia/bundler/issues/131
But setting depCache to false made no difference in my case. Why is SystemJS trying to load this module separately from outside of the bundle?
I was able to reproduce this error locally.
Presuming that you have a Windows environment, it will be a case-sensitivity issue.
After renaming [P]ages folder to [p]ages, bundled version works as expected.
On the filesystem there is a [P]ages/welcome.js viewmodel, but [p]ages/welcome has been defined as moduleId.
Unbundled mode: Windows filesystem is case-insensitive, which behaviour can be misleading by loading [P]ages/welcome.js correctly.
Bundled mode:
Based on file path, bundling process embeds[P]ages/welcome.js as [P]ages/welcome module.
But, according to the route config, SystemJS will be looking for [p]ages/welcome module within app-build.js.
My recommendation would be to use lowercase folder/filenames whenever it's possible.
I'm just playing around with an index.html file and an accompanying CSS file that I'm viewing in my web browser. How do I allow this to work with TypeKit? I know I can have it work if I have a webserver with localhost running, but in this case I don't.
If you have some working webserver, you can configure the typekit to use that domain, upload the index.html there, and then rip the typekit CSS to use it locally. The fonts are included as data URIs.
To do that, for example, in Chrome: Open the dev tools, go to the network tab, reload the hosted page and look for a CSS file from use.typekit.net (d?abcde2134...). Then copy the data from the preview tab into a local CSS file and you're good to go.
When publish a site in local IIS it shows an exception system cannot find the file specified. But same code work fine in debug mode is there any solution for this.
Read the path from web config file.
Check if the missing file is part of your project in the project explorer. If it is not part of your project, then it will not be published, but it nevertheless may work in debug mode, because the file(s) are locally available.
We have an MVC 4 application that has 4 resource files. The default one (Resource.resx), one for Chinese and German (Resource.zn-CH.resx and Resource.de-DE.resx) and then one for a custom language (Resource.en-PI.resx (English-Pirate)) for testing purposes.
Every setting for all of the resource files is exactly the same:
Build Action: Embedded Resource
Copy to Output Directory: Copy Always
Custom Tool: PublicResXFileCodeGenerator
Custom Tool Namespace: Resources
Whenever the application is built locally, in the bin folder we get the folders de-DE, en-PI and zh-CN which all include a dll named (ProjectName).resources.dll.
The problem is whenever this application is deployed to our DEV server the folder for en-PI is ignored and not copied and we have to manually copy that folder over for the en-PI language to work.
We have a build definition that will build the necessary projects to a certain folder and do other things and then copy them over to our DEV server. Everything works perfectly fine for the other 2 languages (de-DE and zh-CN) but the en-PI folder doesn't show up in the bin folder. Is there some setting somewhere that is causing this resource file not to be deployed because it is a custom language?
The way all of these resource files were added followed this example http://odetocode.com/Blogs/scott/archive/2009/07/16/resource-files-and-asp-net-mvc-projects.aspx
Figured it out. Microsoft explains it here under the section Resource Naming Conventions. Because the language is a custom language and has a custom code it doesn't have a name that the common language runtime expects which is why it doesn't get deployed correctly.