I imagine in less than a decade we may see a fragmentation of front end development into perhaps two or more divisions, starting with javascript app developers. The primary focus is on HTML, CSS, and Javascript, even if we abstract ourselves from it with technologies like JSX, Sass, and TypeScript. The great unifier between these professions is the core technologies: we all live and die (primarily) in the browser. It's also a wild mix of several professions including but not limited to: app developers, animators, data visualization architects, content/information architects, CMS (content management system) templaters, UX/UI designers, all residing under a very wide umbrella called front end development. Readers may want to revisit my previous review for context as I spend more time explaining the usefulness of a task manager and Sass.įront End Development is wildly a caustic field to learn as every week we're talking about some hot new JS framework.
To explain the differences between CodeKit 2 and 3 requires certain vernacular, vocabulary, terminology, and industry acronyms. I'd like this review to be as accessible to novice coders and beginners as possible, but it will inevitably be more technical. It seems fitting that this now is officially the most longspun single article I've written for my blog edit: oh how naive I was when I wrote this, now that I have a 20,000+ word article. As the saying goes: Imitation is the highest form of flattery. The review was popular enough to be ripped off by a few hack writers on other blogs like which managed to use a verbatim copy of my review's final points. It was a meditation on task management in the world of front end development. Back in January of 2015, I posted the longest continuous blob of text I had written since college, a review titled 9 months with Codekit 2: A review.
GET CSS FILE BACK THAT PREPROS WROTE OVER HOW TO
You say that webpack.resolve knows how to do it, but I can't imagine that it knows all the Sass-specific rules for when to add underscores for partials or the relative precedence of. You don’t have to think about webpack.resolve, it can changed and improved anytime, for example we want to implement remote resolving. My question is, how do you make sure a Webpack-specific string like ~name checks for Sass-specific names like _name.scss and webpack.resolve known how to do it.
GET CSS FILE BACK THAT PREPROS WROTE OVER CODE
By the time you get to the webpack.resolve() call, the code isn't doing anything Sass-specific. In your example code here, you try to resolve a URL using sass.resolve() and then, if that fails, try resolving it using webpack.resolve(). What's the problem if color-utils exists at node_modules/color-utils? If it's just a package with JS files, doesn't that mean that the plain Sass importer won't work either? In other words, the importer still gets to do all its Webpack-specific logic and pop out whichever result would be correct for and Sass will handle adjusting that result for This is why sass-loader does not have to emulate different logic for and you run sass-loader it try to resolve color-utils module and in theory color-utils can be exists at node_mdoules/color-utils (it is just a package with JS files). After your importer returns package/, if package/ exists and an is being resolved, Sass will convert the response to package/. īut if you do return the latter result, import-only files will automatically work without any need for extra logic in sass-loader. Now we can not fully emulate sass resolution system because we don't know is it or because sass uses difference logic. All issues with wrong resolutions in sass-loader repo because of this.
And when something added or changes in sass algorithm, we need fix it too. To achieve this we emulate sass resolving algorithm. We cannot ask sass - "Can you resolve it or not?". Why? Because sass-loader uses webpack.resolve and webpack.resolve supports more abilities (I can demonstrate many more examples with problems).
0 kommentar(er)
