profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/dreyks/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Roman Usherenko dreyks @railsware Kyiv

dreyks/cashtrails 1

web-interface for iOS Cashtrails app

dreyks/ir_black 1

256-color friendly ir_black theme for Vim

dreyks/minified_erb 1

Minified HTML generator for popular ERB implementations

dreyks/asset-resource-bug 0

repro example for https://github.com/webpack/webpack/issues/14392

dreyks/astroturf 0

An "artificial" css-in-js for those that want it all.

dreyks/bnp-frontend 0

frontend for bnp

dreyks/bnp-ruby 0

"blocks and pages" - ruby version

push eventdreyks/mf-error

Roman Usherenko

commit sha 70d60a333eac092695c24bb5a6396747f2a1f505

initial commit

view details

push time in 5 days

push eventdreyks/mf-error

Roman Usherenko

commit sha 3603d52c2e6b47747f6fb5f0eb3d5785b83a6eae

initial commit

view details

push time in 5 days

create barnchdreyks/mf-failure

branch : master

created branch time in 5 days

created repositorydreyks/mf-failure

created time in 5 days

issue comment4Catalyzer/astroturf

Persistent cache

yeah I had [hash] but I understand now that I had other issues - match resource being absent due to https://github.com/4Catalyzer/astroturf/issues/727

makenosound

comment created time in 22 days

issue opened4Catalyzer/astroturf

useAltLoader doesn't work with MiniCssExtractPlugin's experimentalUseImportModule

experimentalUseImportModule is a new option for MiniCssExtractPlugin to use importModule instead of a child compilation.

while calling importModule mini-css-extract-plugin prepends the request with the resource which as far as I understand adds the matchResource to the module.

this leads to astroturf not attaching its own matchResource here

this, in turn, leads to CSS not being processed as CSS modules and then astroturf can't find any CSS Module imports since there are none

my understanding of how things work (especially in the context of matchResource) is limited and mostly comes from the discussion in your PR to css-loader so I might be mistaken here :)

also, If I comment the conditional in astroturf and just reassign this._module.matchResource = style.absoluteFilePath unconditionally - everything seems to be working for me. I don't, however, fully understand the consequences of this action.

created time in 22 days

issue commentwebpack/webpack

asset/resource builds outside of dist when [pathname] contains references to hoisted node_modules

well... I don't really remember why it was done like this (years ago). I think I'll just use the defaults now, was just surprised that webpack5 behaves differently than file-loader

dreyks

comment created time in 22 days

issue commentwebpack/webpack

asset/resource builds outside of dist when [pathname] contains references to hoisted node_modules

@alexander-akait yes, I'm using a monorepo powered by yarn workspaces. which hoist all the node_modules to the root level.

what do you mean by "default values"?

dreyks

comment created time in 22 days

issue commentwebpack/webpack

asset/resource builds outside of dist when [pathname] contains references to hoisted node_modules

hmm... I see. I'll probably have to drop the [pathname] part as a workaround

dreyks

comment created time in 22 days

issue commentwebpack/webpack

asset/resource builds outside of dist when [pathname] contains references to hoisted node_modules

the thing is i want context to remain . because that's where the app code is. the ../ crops in only because of how workspaces hoist node_modules. Additionally, as you can see from my example file-loader doesn't have this issue - it replaces all .. with _ and the path becomes dist/_/node_modules/....

dreyks

comment created time in 22 days

issue comment4Catalyzer/astroturf

Persistent cache

I'm getting has collisions when using alt loader

this happens when there are several styled components in a single js file. alt loader attaches the component name as a query path/to/file.js?ComponentName, but css-loader only considers the resourcePath part. Since the cls1/cls2 class names are same for all the components this leads to same hashes https://github.com/webpack-contrib/css-loader/blob/b29d3899f8130e77e1ad6cf4c4c2fe18116abcd1/src/utils.js#L323

I'm not really sure how to proceed with this since css-loader doesn't expose something like a [query] placeholder

makenosound

comment created time in 22 days

issue openedwebpack/webpack

asset/resource builds outside of dist when [pathname] contains references to hoisted node_modules

<!-- Please don't delete this template because we'll close your issue --> <!-- Before creating an issue please make sure you are using the latest version of webpack. -->

Bug report

<!-- Please ask questions on StackOverflow or the webpack Gitter. --> <!-- https://stackoverflow.com/questions/ask?tags=webpack --> <!-- https://gitter.im/webpack/webpack --> <!-- Issues which contain questions or support requests will be closed. -->

What is the current behavior?

Files located in hoisted node_modules of a workspace and loaded as asset/resource are built outside of dist. This differs from what file-loader does

If the current behavior is a bug, please provide the steps to reproduce.

https://github.com/dreyks/asset-resource-bug

<!-- A great way to do this is to provide your configuration via a GitHub repository --> <!-- The most helpful is a minimal reproduction with instructions on how to reproduce --> <!-- Repositories with too many files or large webpack.config.js files are not suitable --> <!-- Please only add small code snippets directly into this issue --> <!-- https://gist.github.com is a good place for longer code snippets --> <!-- If your issue is caused by a plugin or loader, please create an issue on the loader/plugin repository instead -->

What is the expected behavior?

All built files should end up inside the dist folder no matter where they are located on the fs

<!-- "It should work" is not a helpful explanation --> <!-- Explain exactly how it should behave -->

Other relevant information: webpack version: webpack@5.56.0 Node.js version: v14.13.1 Operating System: MacOS Additional tools:

created time in 23 days

push eventdreyks/asset-resource-bug

Roman Usherenko

commit sha 1945e16e0e13cda329b78ed7c95a6af61e6dae9e

initial commit

view details

push time in 23 days

create barnchdreyks/asset-resource-bug

branch : master

created branch time in 23 days

created repositorydreyks/asset-resource-bug

created time in 23 days

push eventdreyks/dotfiles

Roman Usherenko

commit sha f76eddbd74c240c72a3fd1c17f4995605fb7742c

set git default branch to master

view details

push time in 23 days

issue commentwebpack/webpack

BuildCycleError with a module blocking itself

i see. the most interesting thing is that if I remove this failsafe mechanism the build does not hang. that's why I thought blocking on itself was not a "real" blocker and can be removed

dreyks

comment created time in 25 days

issue commentwebpack/webpack

BuildCycleError with a module blocking itself

is this something that can be addressed in webpack or is this the responsibility of the library code?

dreyks

comment created time in 25 days

issue commentwebpack/webpack

BuildCycleError with a module blocking itself

is this something that can be addressed in webpack or is toss the responsibility of the library code?

dreyks

comment created time in 25 days

issue commentwebpack/webpack

BuildCycleError with a module blocking itself

oh so this happens if some module gets loaded using both "normal" import and a loadModule/importModule through a loader?

dreyks

comment created time in a month

issue commentwebpack/webpack

BuildCycleError with a module blocking itself

yeah astroturf does this

https://github.com/4Catalyzer/astroturf/blob/386a73b8db290d6eb46ee61119b552b79c74d419/src/inline-loader.ts#L68

dreyks

comment created time in a month

issue commentwebpack/webpack

BuildCycleError with a module blocking itself

unfortunately, no. I've tried but no matter how many interpolations I add it still doesn't deadlock. I think it has something to do with race conditions that only show up in a big project

dreyks

comment created time in a month

issue openedwebpack/webpack

BuildCycleError with a module blocking itself

DISCLAIMER: I don't have a minimal reproduction example, I only have this issue in a big project which I can't share. I understand that this issue might be closed because of this, but maybe you'll help me to understand if it's even a bug of webpack

<!-- Please don't delete this template because we'll close your issue --> <!-- Before creating an issue please make sure you are using the latest version of webpack. -->

Bug report

<!-- Please ask questions on StackOverflow or the webpack Gitter. --> <!-- https://stackoverflow.com/questions/ask?tags=webpack --> <!-- https://gitter.im/webpack/webpack --> <!-- Issues which contain questions or support requests will be closed. -->

What is the current behavior?

I have a big project that uses https://github.com/4Catalyzer/astroturf for styling. I have several places where I have a ton of styles interpolating each other but this is working fine with webpack@4.

Now I am trying to upgrade to webpack@5 and I'm getting an error saying There is a circular build dependency, which makes it impossible to create this module

If the current behavior is a bug, please provide the steps to reproduce.

Unfortunately, I am unable to create a minimal example, see the disclaimer above.

<!-- A great way to do this is to provide your configuration via a GitHub repository --> <!-- The most helpful is a minimal reproduction with instructions on how to reproduce --> <!-- Repositories with too many files or large webpack.config.js files are not suitable --> <!-- Please only add small code snippets directly into this issue --> <!-- https://gist.github.com is a good place for longer code snippets --> <!-- If your issue is caused by a plugin or loader, please create an issue on the loader/plugin repository instead -->

What is the expected behavior?

There should not be any unsolvable cyclic dependencies because webpack 4 is able to build the same app

<!-- "It should work" is not a helpful explanation --> <!-- Explain exactly how it should behave -->

I've tried to solve it myself which lead me to here https://github.com/webpack/webpack/blob/b7f382878e50452d02c7ad1eeaf28f14d40b29ce/lib/Compilation.js#L1814-L1831

After some debugging I found out that the blockReasons of the module that causes the cycle is that same module (and it is the only item in the blockReasons), so looks like it "imports itself". This might be an issue in astroturf (so I'm tagging @jquense as its author) but my question to webpack team is the following:

Is it an intended thing that a module can potentially end up blocking itself? I've tried adding a line if (item === module) continue after line 1821 and this resolved all my issues so there's no real deadlock - the build completes

Other relevant information: webpack version: 5.55.1 Node.js version: v14.17.0 Operating System: MacOS Additional tools: astroturf version 1.0.0-beta22 (latest)

created time in a month

issue comment4Catalyzer/astroturf

Support one class approach

hey! is it intended that css produces a string consisting of 2 classnames? it's not a big deal for react but doesn't work out of the box with vanilla classList.add

user753

comment created time in 2 months