I'm using Spectacle 5 in an npm project, which itself uses Prism as a dependency. The CodePane component correctly highlights code for e.g. python, but for e.g. haskell, no highlighting is being performed (I verified the same code snippet worked at https://prismjs.com/test.html#language=haskell).
I don't see any errors in the web console to indicate an issue. I wonder if I still need to manually include CSS, or if this is perhaps an issue with Spectacle. Maybe a workaround would be to try to use something like the prism component loader? As far as I can tell, npm didn't have components for individual languages, and it seemed to be implied that the default is to load all language components.
Related
I have noticed theese two methods for generating a new vue project:
npm init vue#latest
and
vue create <projectName>
Both seem to do the job, but very differently, they boundle very different packages.
Even tho you ovbiously modify the project to your liking, is ther a better start for my project requirements?.
The project i'm talking about, is going to be a single page web application using typescypt, ESlint and tailwind.
Also I have seen that the two methods do not just install unrelated software from one to the other, for example state management is handled by different libraries, and if I am not wrong Vite is the equivalent to Babel.
I am just starting with Vue, and frontend in general (tho i have used Angular), I am more prominently a backend dev, so i am not used to most of the software used here, and I do not really know what they are used for....
To ease finding the solution for others, as commented by Estus Flask, The oficially recomended by the vue devs currently is
npm init vue#latest.
This will set up a project using Vite and Rollup, wich is the currently recomended stack.
The other method is a deprecated one. as it gives you the old stack recomendation, Vue CLI and Webpack, this other stack is currently not enforced by vue devs.
Recently, node package manager is very popular and doing a lot of job for us, however it is really difficult to understand what is going on under the hood. I really like simple tags to insert Vue, Babel etc. Haven't worked on big projects, I really wonder is there any disadvantages using script tags over npm-cli.
When you npm install a library, plugin, extension, etc it can be declared as a dependency with a --save flag. In doing so it is marked as a dependency in your package.json file, which is key to version control for your dependencies. If you just use the CDN you are pulling in a path to a library that may be deprecated at some point in the future.
During development it is ok to use CDNs, but in production it is not good practice for dependencies (though I do it for certain exceptions, such as a google font).
I have made a few applications (using webpack, babel, react, d3, npm etc.) that uses very similar charting code. I am in the process of splitting out that charting code into an npm package which multiple apps can then import.
To test this out, I've embedded a demo app inside my chart libraries project directory and install the library at its file path. Now, presumably i'll be able to install this in depending apps A, B and C and so on, and I can change my chart libary and all apps will reflect these changes.
The first thing I noticed is that I now have to cd into my chart library and run npm run build (which runs webpack) any time I change something, and then cd into the depending app I'm working on and run npm i. This can perhaps be improved by using npm link but there are issues there as well (such as versioning and deploying to my server). So my first question is about what a decent rapid development approach looks like now that my charting code is in a separate npm project.
The other problem I've noticed is that I've lost two valuable features with respect to my chart library code. Code completion in VSCode and debugging in chrome dev tools. I'm not sure why VSCode code completion has stopped working. And for debugging, how would i be able to debug both my depending app and the library its depending on at the same time in chrome?
I would use npm link. It's immensely helpful when working on a library and its integration side by side.
Check the Chrome settings to make sure it's not instructed to skip libraries in Settings -> Framework Blackboxing, see e.g., http://blog.edenhauser.com/tell-chrome-debugger-to-ignore-libraries/.
I seem to have syntax highlighting in VS Code, without installing any specific Vue extensions (in fact, when I run code --disable-extensions). However from what I've seen around the web / friends, a vue extension is needed as VS Code does not support Vue out of the box.
Does it support Vue or not? I checked the release notes of the last few months, haven't found anything Vue related there. And if it does support Vue, why are there a few Vue extensions out there that provide syntax highlighting?
Disclaimer: Former VSCode intern. Working on vetur, a VSCode extension for vue:
https://github.com/octref/vetur
https://marketplace.visualstudio.com/items?itemName=octref.vetur
Short answer: No.
Long answer:
VSCode has been use its html extension for vue SFC. That works fine with html/css/js, but not pug/sass/scss/less/stylus/typescript/coffee.
By "works fine", I mean VSCode has correct syntax highlighting, some IntelliSense, formatter and error checking, for html/css/js.
VSCode has no intention to add vue-specific support in its html extension, like scss support, etc. So I started to work on vetur. Initially I just wanted better syntax highlighting, but now I have reworked vue component's grammar and ported VSCode's html extension to support vue, so you get complete syntax highlighting, some IntelliSense, error-checking and formatting.
Here is a list of implemented features:
Basic IntelliSense for html/css/scss/less/js
Linting for css/scss/less/js
Syntax highlighting for:
html/jade/pug
css/sass/scss/less/stylus
js/ts
Embedded snippet support
Use vue snippet outside all regions
Use each language's snippet inside its region
emmet for html/css/sass/scss/less
Vue is just a javascript library so, yes, you can edit Vue code in VSCode. However, there's things like "Single File Components" that make using Vue much, much easier. VSCode can edit .vue files as well, but to process those you need something like webpack or Browserify to post-process them into browser-friendly code.
I am curious to know why when I create a new Aurelia project, each project installs +600 node_modules. Understandably, the modules collectively don't take up a lot of space, but are all of these modules necessary? I was under the impression that Aurelia's aim was to help developers move away from depending on 3rd party libraries so it seems odd that each project comes with a massive dump of 3rd party libraries.
My guess is that you are starting your project from CLI - which comes preset with HTTP server, ES6/2015, SASS, live-reloading and more.
I created clean Aurelia project and looked at the package.json - there were 5 dependencies and 34 dev dependencies. Using all of above mentioned tools is somewhat standard in today's JS web development, and generating project from CLI reduces time needed for upfront setup. All of these features come with their own dependencies, and that's why node_modules/ folder grows rapidly.
The bottom line is - you could start new Aureila project with much fewer dependencies. On their home page you can find starter project with just three. But that also means that you won't have access to most of the tools used today.
Also, and correct me if I'm wrong, I haven't got the impression Aurelia ever aimed to move devs from third party libs and modules, just to be modern, fast, and unobtrusive.
All modern web frameworks have a host of tooling. The reasons in no particular order -
1. Transpiling ESNext or TypeScript - if you want to write in Future JavaScript but have it work in all browsers, you need this step. Both Babel and TypeScript tooling comes with extra stuff too. If you want to see coverage (everyone does) there's another tool.
2. Testing - Unit test and End to End testing require testing frameworks, test runners, and if you want to write like above (esnext or TypeScript) you also need transpiling.
3. Module Loading / Bundling - Require.js, JSPM/System.js, WebPack, etc... are used to allow your code to actually run in the browser. Without a module loader you could not break your code out in to separate files. Without a bundler you would be loading a lot of extra files in production.
4. Serving your application - If you want to run your app locally you need a way to serve it up and watch for changes.
5. Debugging - You want to debug? Now you need a way to debug the file that gets served to the browser back to the original source.
6. Linting - Lint your code base for style consistencies.
Each of these packages usually have their own dependencies, and they get pulled down as well.
This convention of small packages that have a single focus is arguably better than massive packages that do everything for you. This allows you to remove a package and replace it with the one that does the same thing but in a way you want it.