Yeah, but that’s not great - then many users would end up shipping products which contain blaze in their bundles, for one transient administration feature, if they don’t remove that package.
This is true. Better to just re-create them in svelte.
Honestly, I’ve never used the accounts-ui package, so I’m not even sure how important it is.
I still think it’d be better to avoid that. Honestly, it’s not that hard to set up all the same stuff in code and that has additional benefits (for example, once you have a text file, it’s easy to update things if you need to, whereas the UI based config is a constant pain - this is from experience), and personally, I’d prefer the tutorials lean that way in these cases. That’s just my opinion though.
If the tutorials do leave it there, hopefully they explain that it’s just for configuration, and it should be removed after?
I think it’s kind of like the autopublish
package - it seemed like a good idea to make things super easy for early adopters, but it’s time has passed.
i think the point of the to-do step by step guide is to be for a beginner to see all the moving parts in action. Not so much as a demonstration of best practice (which i agree with you guys, using blaze is uneeded its only purpose is to quickly get the login form to be brought in to the step by step guide to let the demonstration proceed )
that was the audience i was shooting for anyway with them. Get beginners using svelte and vue with meteor and then grow a user base, who will make use of the packages people have made to support those frameworks.
I also fee like if your a beginner and you go the meteor site and click the tutorials link you have 3 options
blaze (which youve prob never heard of), anglarjs which seems kind of dated, or react. So react is the most natural choice. But if we had a vue and svelte step by step guide. they could play around with all of them. and make a choice. They would all be almost identical in content so no heavy lifting to switch around. and it gives an up to date appearance in my opinion.
Just created an account to stop by and say I would really love if @stolinski did a course at LevelUp on Meteor and Svelte. I’m still a novice at both (and JavaScript in general) but I haven’t come across two frameworks that are more fun to work with. Realtime apps with all of the scoped styles and JS of Svelte components sound great but, as I said, still a novice and could definitely use the guidance of a structured course on working with both frameworks together.
Also, awesome work putting this together!
Hi everyone,
I’ve been trying out svelte with meteor. While setting up the environment, I’ve found an obstacle. I did set path aliases for meteor but I couldn’t figure out how to apply it to svelte. In the answers that I’ve found,none of them uses only the compiler. The only thing that I’ve found is related to roll-up. So if you can help me make it work for both environments, svelte and meteor, in a way that is accessible for both, I will appreciate it a lot.
Only config you need is:
- Install svelte from NPM
- Install the beta integration: svelte:compiler@4.0.0-beta.0! (if you upgrade from 3.x, make sure you reset your project, or you’ll get baffling errors…)
- Add NPM svelte package to “meteor.nodeModules.recompile” in
package.json
Check out my meteor-svelte-starter repo for examples.
(Er, are you maybe trying to use some specific svelte compiler package I’m not familiar with?)
I think that you didn’t understand the entire question, or maybe did not read it in full. I’m trying to find help regarding:
- setup Eslint for both Meteor and Svelte. (There are some conflicts).
- setup module import path aliases. I was able to set it for meteor, but not for svelte.
ESlint has been a pain to get set up with Svelte (and with typescript). I haven’t gotten anything working perfectly (with VSCode). If you do get something working, please share! Your original question didn’t mention eslint at all…
If you update to svelte:compiler@4.0.0-beta.0, you’ll be using the npm version of the svelte compiler:
meteor add svelte:compiler@4.0.0-beta.0
meteor npm i svelte
Note what I said about meteor reset
- if you don’t do that, you’ll get errors that look like a conflict, because the build cache is not properly cleared when upgrading from svelte:compiler
3 to 4. (That’s the main reason 4.0 hasn’t been released.)
I’m not sure what you mean by path aliases, but you’ll likely be constrained to fiddling with babel config. I’ve used “babel-plugin-transform-imports” for various things in the past. Maybe look in to that one.
Here’s an example that doesn’t exactly match your reqs, but might provide a hint (as configured in package.json, .babelrc is similar):
{
"babel": {
"plugins": [
[
"transform-imports",
{
"@material-ui/core": {
"transform": "@material-ui/core/${member}",
"preventFullImport": true
},
"@material-ui/icons": {
"transform": "@material-ui/icons/${member}",
"preventFullImport": true
},
"@material-ui/styles": {
"transform": "@material-ui/styles/${member}",
"preventFullImport": true
},
"uniforms": {
"transform": "uniforms/src/${member}",
"preventFullImport": true
},
"uniforms-material": {
"transform": "uniforms-material/src/${member}",
"preventFullImport": true
}
}
]
]
}
}
If you are looking to change the root of your import statements, you could use something like: https://www.npmjs.com/package/babel-plugin-root-import